Team Topologies

Most delivery problems that look like performance problems are structural. A team that can't ship without three other teams' approval isn't slow because its engineers are slow; it's slow because the organization was drawn without regard to how work actually flows. Adding people to that team makes it worse.

Team Topologies — the framework from Matthew Skelton and Manuel Pais — treats team structure as a design problem with a small vocabulary: four team types, three ways teams interact, and one binding constraint, which is cognitive load. A team can only hold so much in its head, and when its responsibilities exceed that, quality and speed both degrade regardless of headcount.

Underneath it sits Conway's law: organizations produce systems that mirror their communication structures. This is usually cited as a warning and is more useful as a lever. If you want a modular system, build modular teams — the architecture follows.

TL;DR

The Four Team Types

The proportions matter. In a healthy organization the large majority of teams are stream-aligned, with a small number of platform teams, one or two enabling teams, and very few complicated-subsystem teams. An organization with many specialist teams and few stream-aligned ones has built a structure where every piece of customer value requires coordination across four boundaries.

What stream-aligned means in practice

Layer-based teams guarantee that every unit of value requires coordination. The point of stream alignment is that a team can take a customer-facing change from idea to production without waiting for anyone — which is also what makes DORA lead time improvable.

Cognitive Load

This is the framework's most useful idea and the one most often ignored.

The practical test: a team should own no more domains than it can hold in its head. If nobody can explain the whole of what the team owns, it owns too much — and the response is to reduce scope or reduce extraneous load, not to add people. Adding people to an overloaded team increases communication overhead against the same cognitive ceiling.

Interaction Modes

That progression is the useful diagnostic. Two teams that have been "collaborating closely" for a year either should be merged or have a boundary in the wrong place.

Conway's Law as a Tool

Organizations produce designs which are copies of their communication structures. — Melvin Conway, 1967

The inverse Conway manoeuvre is to design the team structure you need for the architecture you want, and let the architecture follow. It's slow and it works better than trying to impose an architecture on an organization shaped against it — which is why microservices adopted without reorganizing produce a distributed monolith with all the operational cost and none of the independence.

Platform Teams

The most commonly built and most commonly misbuilt team type.

The single most reliable indicator: would teams use it if they didn't have to? A platform that must be mandated is a bottleneck with a nicer name — it has become a gate rather than an accelerator, and the teams routing around it are giving you accurate feedback.

Sizing is worth stating too: a platform team of three serving forty engineers is under-resourced and will become a queue. Platform work is product work, and it needs product-level investment. See Platform Engineering.

Best Practices

Default to stream-aligned

Start every structural conversation with "which flow of value does this team own end to end?" Specialist teams should have to justify their existence against the coordination cost they impose.

Size by cognitive load, not by headcount

Ask what the team owns, not how many people it has. If no one on the team can explain the whole scope, reduce it — split the team, hand something to a platform, or delete something.

Make platform adoption voluntary

Then measure it. Voluntary adoption is the only honest signal about whether a platform is good, and mandating it removes your ability to tell. If teams are routing around your platform, find out why rather than closing the escape route.

Time-box collaboration

Every collaboration engagement should have an end date and a target: "after this quarter, this becomes X-as-a-Service." Open-ended collaboration between two teams is a boundary problem wearing a process costume.

Keep teams long-lived and stable

Team performance is largely accumulated context — of the code, the domain, and each other. Reshuffling resets it. Move work to teams rather than moving people between teams, and treat reorganizations as expensive rather than as a routine lever.

Give every team clear ownership boundaries

Written down: which services, which data, which customer flows. Ambiguous ownership produces both gaps (nobody owns the flaky integration) and conflict (two teams changing the same thing). This is also the prerequisite for a meaningful on-call rotation.

Watch for organizational pain as a structural signal

Chronic cross-team dependencies, features that require four teams, and repeated "we're blocked on another team" are structural diagnoses, not people problems. So is a rising lead time with no change in the codebase.

Use enabling teams instead of permanent specialists

A short-lived enabling engagement that transfers a capability — testing practice, observability, security review — leaves the receiving teams stronger. A permanent specialist team makes them permanently dependent and becomes a queue.

Common Mistakes

Teams organized by technical layer

A platform team that gates

Overloading a team and adding people

Microservices without reorganizing

Permanent collaboration

Frequent reorganization

FAQ

How big should a team be?

Five to nine, with seven a common target. Below five it's fragile — one person's absence is significant. Above nine, communication paths grow quadratically and the team fragments informally anyway. This aligns with the "two-pizza team" heuristic and with the practical limit on how many one-on-ones a manager can run well.

Do we need a platform team?

Not below roughly thirty to fifty engineers. Before that, a platform team is likely to be one or two people building infrastructure nobody asked for while stream-aligned teams handle their own perfectly well. The signal that you need one is repeated duplication: several teams independently solving CI, observability, or deployment, badly and differently. See Platform Engineering.

What about SRE, security, and data teams?

Depends on how they operate. An SRE or security team that provides self-service tooling, standards, and consulting is functioning as a platform or enabling team, which is healthy. One that reviews and approves every change is a gate, which becomes the constraint on every stream-aligned team. The distinction is whether their output is capability or approval.

How do we get from a layered structure to stream-aligned?

Gradually, and starting with one value stream rather than a big-bang reorganization. Pick a high-value flow, form a team with everything it needs to ship end to end, give it real ownership, and let it demonstrate the difference. Expect friction on shared systems that were built assuming layer ownership — that's the technical debt the old structure created, and it becomes visible immediately.

Isn't this just microservices with extra vocabulary?

No — it's about teams, and it applies to a monolith. A well-modularized monolith with clear ownership per module and independent deployability is entirely compatible with stream-aligned teams. Team Topologies argues that team structure should drive architecture rather than the reverse, which is close to the opposite of "adopt microservices."

How do we handle a shared legacy system nobody wants to own?

The two workable answers are a complicated-subsystem team that owns it explicitly, or assigning it to the stream-aligned team that changes it most. What doesn't work is collective ownership with no name attached — an unowned system accumulates debt, has no on-call, and blocks everyone equally. If it's genuinely being decommissioned, name an owner for the decommissioning.

Related Topics

References