Team design is an architectural act, not an HR one. The four team types and three interaction modes from Team Topologies — plus the decision layer: when each shape fits, and what breaks when it does not.
Team DesignPlatform EngineeringStrategy
Share
The four team types, the three interaction modes, and what sits underneath them
The model below is Matthew Skelton and Manuel Pais's, published as Team Topologies (IT Revolution, 2019) at teamtopologies.com — it is not mine. Each entry summarises their idea, then adds my own read on when it fits and how it fails.
The default type
Stream-Aligned Teams
"A kitchen that owns one menu end to end — never passing plates to another building"
A stream-aligned team is organised around a single valuable flow of work — a product, a service, a customer journey — and owns it from idea to production and beyond. In Skelton and Pais's model this is the default type, and the other three exist to make it effective. The working test is whether the team can get a change to its users without waiting on anyone else. Every handoff you find is a boundary drawn in the wrong place.
Most reorganisations I have watched cluster teams around technologies — a database team, a front-end team, a networking team — because that is how skills cluster on a CV. It optimises for utilisation and destroys flow. One change becomes six tickets across five queues, and lead time gets set by the busiest queue rather than by the work.
The default type
Stream-Aligned Teams
"A kitchen that owns one menu end to end — never passing plates to another building"
A stream-aligned team is organised around a single valuable flow of work — a product, a service, a customer journey — and owns it from idea to production and beyond. In Skelton and Pais's model this is the default type, and the other three exist to make it effective. The working test is whether the team can get a change to its users without waiting on anyone else. Every handoff you find is a boundary drawn in the wrong place.
Most reorganisations I have watched cluster teams around technologies — a database team, a front-end team, a networking team — because that is how skills cluster on a CV. It optimises for utilisation and destroys flow. One change becomes six tickets across five queues, and lead time gets set by the busiest queue rather than by the work.
A product, not a queue
Platform Teams
"A utility company — you consume the power, you do not book time with the engineers"
A platform team provides internal services that stream-aligned teams consume with minimal effort, ideally self-service. What distinguishes it is not what it builds but how it is consumed: if teams have to raise a ticket and wait for a person, that is a shared-services function wearing a platform badge. Skelton and Pais argue for the thinnest viable platform — its job is to reduce cognitive load elsewhere, not to accumulate scope of its own.
Running a central platform for dozens of autonomous business units, the hardest discipline was refusing work. Every 'could you just do this one for us' is a vote to become a queue. A platform that takes tickets cannot scale past its own headcount, and it stops being a platform the day its users cannot get anything done without it.
Time-boxed by design
Enabling Teams
"A coach, not a substitute — they leave once the team can do it"
An enabling team helps stream-aligned teams acquire a capability they are missing — a testing practice, observability, a new deployment model — and then withdraws. The time-box is the whole point. An enabling team allowed to become permanent turns into either a centre of excellence nobody consults or a delivery team quietly doing the work it was meant to teach.
Scaling a cloud function from eight people to a hundred and fifty in eighteen months only worked because the central team taught more than it delivered. Growth by hiring is linear; growth by capability transfer is not. But you have to write the exit date into the engagement at the start, because no engagement has ever volunteered to end.
Use sparingly
Complicated-Subsystem Teams
"The engine team in a racing outfit — deep specialism, one component, everyone else just uses it"
A complicated-subsystem team owns a part of the system that genuinely demands specialist knowledge — a video codec, a pricing engine, a risk model — where expecting every stream-aligned team to carry that knowledge would be unreasonable. Skelton and Pais are explicit that this type should be rare. It is the easiest of the four to over-apply, because every team believes its own subsystem is the complicated one.
The test I use is a hiring test: could a competent engineer be productive on this within a fortnight? If yes, it is not a complicated subsystem, it is merely unfamiliar — and carving a team around it institutionalises a bottleneck. Genuine specialism is rare. The appearance of specialism is mostly missing documentation.
Three modes, chosen deliberately
The Three Interaction Modes
"Doubles tennis, a vending machine, and a driving lesson"
Collaboration: two teams working closely on a shared problem — high bandwidth, high cost, deliberately temporary. X-as-a-Service: one team consumes what another provides with minimal fuss, and the mode most interfaces should settle into. Facilitating: one team helps another improve, then steps back. The argument in Team Topologies is that the mode should be named and given a review date rather than left to emerge, because an unnamed interaction defaults to whatever is politically easiest.
The failure mode is collaboration that never ends. Two teams that were meant to co-design an interface for a quarter are still in each other's stand-ups a year later, and nobody flags it because it looks like good behaviour. If two teams are still collaborating after six months, either the interface is wrong or they are one team.
The real constraint
Cognitive Load Is the Ceiling
"Team capacity is measured in things you have to hold in your head, not in people"
This is the organising principle underneath the whole model. Drawing on John Sweller's cognitive load theory, Skelton and Pais argue that a team's capacity is bounded by how much it can reasonably understand, not by how many people it has — so responsibilities should be assigned to keep each team inside that limit. When a team is struggling, the honest first move is usually to give it less to think about rather than more people to think with.
This is the question I would ask before any reorganisation: what exactly have we asked this team to understand? Adding headcount to a team already past its limit makes it slower, because you have added communication overhead to a comprehension problem. The levers that work are a smaller domain, or a platform that absorbs part of the load.
Architecture follows the org chart
Conway's Law and the Reverse Manoeuvre
"The building always ends up looking like the committee that designed it"
Melvin Conway's 1968 observation is that a system's design mirrors the communication structure of the organisation that built it. Team Topologies builds on it with the reverse Conway manoeuvre: if you know the architecture you want, shape the teams and their interactions to match it and let the architecture follow. It reframes team design as an architectural act rather than an administrative one.
Most monoliths have an org chart underneath them. You cannot decouple a system while the people building it share one weekly meeting and one backlog — the coupling reappears within two releases. Move the boundary in the organisation first and the code follows. Do it the other way round and you will do it twice.
How teams get organised — and what each shape costs
Every rung still ships software. The difference is how much of the lead time is spent waiting for somebody else.
Team design maturity
The right-hand label is what dominates lead time at each rung
The rung that matters is the move from ticketed shared services to platform-as-a-service — that is where dependencies stop setting your delivery dates.
Decision framework
Frequently asked questions
What is the Team Topologies model?
It is a model for organising software teams published by Matthew Skelton and Manuel Pais in Team Topologies (IT Revolution, 2019). It proposes four fundamental team types — stream-aligned, platform, enabling, and complicated-subsystem — and three interaction modes between them: collaboration, X-as-a-Service, and facilitating. The underlying claim is that team boundaries should be drawn to keep each team inside its cognitive load, and that everything else follows from that.
What are the four fundamental team types?
Stream-aligned teams own a single valuable flow of work end to end, and are the default. Platform teams provide internal services that stream-aligned teams consume self-service. Enabling teams help other teams acquire a capability and then withdraw. Complicated-subsystem teams own a part of the system that genuinely demands specialist knowledge, and should be rare. The last three exist to make the first one effective.
What are the three team interaction modes?
Collaboration — two teams working closely on a shared problem: high bandwidth, high cost, deliberately temporary. X-as-a-Service — one team consumes what another provides across a clear interface, which is where most boundaries should settle. Facilitating — one team helps another improve and then steps back. The discipline is naming the mode and giving it a review date, because an unnamed interaction defaults to whatever is politically easiest.
What is cognitive load, and why does it limit team size?
Cognitive load is how much a team has to hold in its head to do its job — the services, languages, datastores, and domain rules it owns. Skelton and Pais apply John Sweller's cognitive load theory to argue that this, rather than headcount, sets a team's ceiling. Once a team is past that limit, adding people adds communication overhead to a comprehension problem and makes it slower. The levers that work are a smaller domain or a platform that absorbs part of the load.
What is Conway's law and the reverse Conway manoeuvre?
Melvin Conway observed in 1968 that a system's design mirrors the communication structure of the organisation that built it. The reverse Conway manoeuvre inverts it as a tactic: decide the architecture you want, then shape the teams and their interactions to match, and let the architecture follow. In practice this is why decoupling a system rarely survives an org chart that keeps the builders in one meeting and one backlog.
What is the most common mistake when applying the model?
Renaming the existing org chart. A shared-services queue relabelled as a platform team still takes tickets; a permanent centre of excellence relabelled as an enabling team still never leaves; and a complicated-subsystem team gets created for work that is merely unfamiliar rather than genuinely specialist. The useful test for that last one is a hiring test: could a competent engineer be productive here within a fortnight? If so, the problem is documentation, not specialism.