# Team Topology Decisions Source: John Bradshaw — https://bradshaw.cloud URL: https://bradshaw.cloud/strategy/team-topologies/ Type: insight Tags: Team Design, Platform Engineering, Strategy > 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. ## 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. ### Stream-Aligned Teams _The default type_ **Analogy:** 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. **Business take:** 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. ### Platform Teams _A product, not a queue_ **Analogy:** 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. **Business take:** 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. ### Enabling Teams _Time-boxed by design_ **Analogy:** 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. **Business take:** 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. ### Complicated-Subsystem Teams _Use sparingly_ **Analogy:** 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. **Business take:** 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. ### The Three Interaction Modes _Three modes, chosen deliberately_ **Analogy:** 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. **Business take:** 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. ### Cognitive Load Is the Ceiling _The real constraint_ **Analogy:** 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. **Business take:** 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. ### Conway's Law and the Reverse Manoeuvre _Architecture follows the org chart_ **Analogy:** 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. **Business take:** 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 - Organised by technology layer — Front-end, DBA, ops, networking — skills clustered, flow broken — Handoffs - Organised by project — Teams assembled and dissolved per initiative — Churn - Stream-aligned, shared services ticketed — Ownership is right; the dependencies still queue — Waiting - Stream-aligned plus platform as a service — Dependencies consumed self-service, not requested — Flow - Explicit interfaces, interactions chosen — Every boundary has a named mode and a review date — Compounding _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 ### Can a team state what it owns in one sentence? **No → the boundary is wrong. Redraw it before you change anything else.** A team needing a paragraph and three exceptions to describe its remit will need the same to hand work over. Ownership you cannot state is ownership nobody has, and every gap between two vague remits becomes a ticket. ### Does your platform team take tickets? **Yes → it is a shared-services function. Fine, but do not plan capacity as though it scales.** A platform is defined by how it is consumed, not by what it builds. Self-service consumption scales with adoption; a request queue scales with headcount. Decide which one you are funding, because the two roadmaps look nothing alike. ### Is this new team doing a job, or being a job? **Enabling and collaboration are time-boxed. Put the end date in the charter.** Enabling teams and collaboration interactions are meant to expire. Without a review date, an enabling team becomes a permanent centre of excellence and a collaboration becomes a standing dependency — both quietly reinstating the coordination cost you were trying to remove. ### Are you adding people to a team that is already overloaded? **Then you are adding communication cost to a comprehension problem. Take work away instead.** Cognitive load, not headcount, sets a team's ceiling. If the team cannot hold what it owns, the levers are a smaller domain, a platform that absorbs the undifferentiated part, or an enabling team for a fortnight. More people is the one lever that makes it worse. ## 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. ## Diagrams Standalone SVG diagrams, licensed CC BY 4.0 with attribution to John Bradshaw — link back to https://bradshaw.cloud/strategy/team-topologies/ when embedding. - [Stream-Aligned Teams (SVG)](https://bradshaw.cloud/strategy/team-topologies/diagrams/stream-aligned.svg) - [Platform Teams (SVG)](https://bradshaw.cloud/strategy/team-topologies/diagrams/platform.svg) - [Enabling Teams (SVG)](https://bradshaw.cloud/strategy/team-topologies/diagrams/enabling.svg) - [Complicated-Subsystem Teams (SVG)](https://bradshaw.cloud/strategy/team-topologies/diagrams/complicated-subsystem.svg) - [The Three Interaction Modes (SVG)](https://bradshaw.cloud/strategy/team-topologies/diagrams/interaction-modes.svg) - [Cognitive Load Is the Ceiling (SVG)](https://bradshaw.cloud/strategy/team-topologies/diagrams/cognitive-load.svg) - [Conway's Law and the Reverse Manoeuvre (SVG)](https://bradshaw.cloud/strategy/team-topologies/diagrams/conway.svg) ## Related - [Platform Operating Model](https://bradshaw.cloud/strategy/platform-operating-model/) — what a platform team has to become once the shape is right. - [Developers as Customers](https://bradshaw.cloud/strategy/developers-as-customers/) — the experience those team boundaries produce. - [Technical Debt Prioritisation](https://bradshaw.cloud/strategy/technical-debt/) — the debt that accumulates when boundaries are drawn badly. - [Build vs Buy](https://bradshaw.cloud/strategy/build-vs-buy/) — the capability question that decides whether you need the team at all. - [Team Topologies](https://teamtopologies.com/) — Matthew Skelton and Manuel Pais’s site for the framework this page reads from. - [All strategy insights](https://bradshaw.cloud/strategy/)