Team Topologies in Practice

The Team Topologies framework, created by Matthew Skelton and Manuel Pais and published in their 2019 book, provides a structured vocabulary for organizing engineering teams. It builds on Conway's Law by defining four fundamental team types and three interaction modes. In EM interviews, you will be expected to use this vocabulary precisely and explain when each team type and interaction mode is appropriate.

The Four Team Types

Stream-aligned teams are the primary value-delivery units. Each stream-aligned team is aligned to a single stream of work -- typically a product area, a user journey, or a business domain. They own the full lifecycle from design through deployment and monitoring. Most engineers in an organization should belong to stream-aligned teams. The goal is for these teams to operate with minimal dependencies on other teams.

Platform teams build and maintain internal platforms that reduce cognitive load for stream-aligned teams. A platform team might own the CI/CD pipeline, the developer portal, the shared authentication service, or the observability stack. Their customers are other engineering teams, not end users. A well-run platform team treats its internal offerings as products -- with documentation, SLAs, and feedback loops.

Enabling teams help stream-aligned teams acquire new capabilities without creating long-term dependencies. An enabling team might specialize in areas like security, data engineering, or test automation. They work with a stream-aligned team for a limited period, transfer knowledge and tools, and then move on to help another team. The key distinction is that enabling teams do not own production services; they build capability in others.

Complicated subsystem teams exist when a component requires deep specialist knowledge that would overwhelm a stream-aligned team. Examples include a real-time video encoding engine, a machine learning inference pipeline, or a financial risk calculation system. These teams own a specific subsystem and expose a clean API for stream-aligned teams to consume.

The Three Interaction Modes

How teams interact is as important as how they are structured. Team Topologies defines three explicit interaction modes:

Interaction Mode	Description	When to Use
Collaboration	Two teams work closely together on a shared goal with high bandwidth communication	During discovery phases, when building something new, or when team boundaries are unclear
X-as-a-Service	One team provides a capability that another team consumes through a well-defined API or platform	When the interface is stable, the service is mature, and the consuming team should not need to understand internals
Facilitating	One team (usually enabling) coaches another team to help them adopt a new practice or technology	When a stream-aligned team needs to build a new capability but lacks the expertise to do it alone

The critical insight is that interaction modes should evolve over time. Two teams might start in collaboration mode while building a new service together, then shift to X-as-a-service once the interface stabilizes. If an interaction stays in collaboration mode permanently, it signals that team boundaries are wrong and should be redrawn.

When to Split or Merge Teams

The primary signal for splitting a team is cognitive load. This concept, rooted in John Sweller's cognitive load theory from cognitive psychology, refers to the total amount of mental effort required to understand and work within a system. When a team owns too many services, too many domains, or too complex a codebase, individual engineers cannot hold enough context in their heads to make good decisions quickly.

Signs a team needs to be split:

• Engineers frequently say "I do not know how that part works" about code their team owns
• On-call rotations are overwhelming because the team supports too many systems
• Sprint velocity drops despite no change in team size, because context-switching costs are rising
• Pull request review quality declines because reviewers lack domain knowledge for certain areas

Signs teams should be merged:

• Two teams consistently block each other on shared interfaces
• Most work items require coordination across both teams before they can ship
• Each team is too small (fewer than 4 people) to sustain independent delivery
• The domain boundary between the teams was drawn incorrectly and creates artificial friction

Common Anti-Patterns

The bottleneck shared services team. When a single "platform" or "shared services" team is responsible for deploying, configuring, or approving changes for multiple stream-aligned teams, it becomes a bottleneck. Every team's velocity is capped by the shared team's throughput. The fix is to either embed the capability directly in stream-aligned teams or to build true self-service platforms with X-as-a-service interaction.

The platform team with no customers. A platform team that builds infrastructure or tooling without regular feedback from the teams it serves will build the wrong things. Platform teams must treat stream-aligned teams as customers -- running surveys, tracking adoption metrics, and prioritizing based on the pain points of their users, not their own technical interests.

The permanent collaboration trap. Two teams that are always "collaborating" are really one team with an artificial boundary. Sustained collaboration mode increases coordination costs and diffuses ownership. If two teams need to collaborate intensely for more than a few weeks, consider merging them or redrawing the boundary.

The enabling team that becomes a dependency. An enabling team that never hands off its work effectively becomes a permanent consulting arm. Stream-aligned teams start relying on them instead of building capability internally. Enabling teams must have time-boxed engagements with clear exit criteria.

Migrating from Legacy Org Structures

Most organizations do not start with clean topologies. You inherit component teams (frontend team, backend team, QA team), project-based teams, or matrix structures. Migration happens in stages:

1. Map current state -- Identify which teams exist, what they own, and how they interact
2. Identify the biggest friction points -- Where are handoffs causing delays? Which teams are overwhelmed?
3. Start with one stream-aligned team -- Pick a product area and form a cross-functional team that owns it end-to-end
4. Evolve gradually -- Shift other teams toward the target topology as you learn what works, adjusting based on cognitive load signals
5. Formalize interaction modes -- Make explicit agreements about which teams collaborate, which consume services, and which facilitate

In interviews, describing a deliberate migration path rather than a "big bang reorg" demonstrates maturity and practical judgment.

Next, we will examine engineering process design -- how to build sprint planning, incident management, tech debt management, and RFC processes that scale with your organization. :::