DEEP READING · READ 922

Team Topologies

Team Topologies · Matthew Skelton & Manuel Pais · 2019

中文 →

In One Sentence

The book makes one claim and makes it all the way down: org design is not an HR matter, it is an architectural decision — the team chart you draw today is the system diagram you will certainly have in three years. So stop waiting for the architecture to rot before reorganising. Design the teams first — bounded cognitive load, boundaries aligned with the business, and every inter-team relationship explicitly chosen — and modularity in the software will follow. The entire toolkit is two lists: four team types and three interaction modes.

Where It Sits

Skelton and Pais came out of DevOps consulting; the book was published in 2019 by IT Revolution, the same house behind The Phoenix Project and Accelerate. Its position in the engineering-org shelf is unusual: it is not about how an individual gets things done (that is The Effective Engineer) or how to manage people (that is The Manager's Path). It is about what the relationship between two teams should be — a layer almost nobody has ever deliberately designed. The book is short, dense, and almost entirely silent on process and tooling; every ounce of its effort goes into boundaries.

The Central Claims

• Organisation design and software architecture are two faces of the same thing, because Conway's Law cannot be defied. Rather than absorbing it passively, use it: decide the architecture you want, then build the teams that will produce it.
• The unit of delivery is the team, not the individual. Teams should be long-lived and own something definite, and work should flow to teams. Treating people as reassignable resources destroys delivery capability continuously.
• Bounding a team's responsibilities is really bounding its cognitive load. A system a team cannot hold in its head will not be built well no matter how the backlog is prioritised — "just look after this one more service" has a real ceiling.
• Four team types are enough, and three interaction modes are enough. Every other exotic team in your org should be folded into one of the four, and every ill-defined collaboration should be named as one of the three — and the mode should be deliberately switched over time.

The Core Ideas, One by One

Conway's Law and the Reverse Conway Maneuver

Conway's Law comes from Melvin Conway's 1968 paper "How Do Committees Invent?": organisations which design systems are constrained to produce designs that are copies of their own communication structures (paraphrased). It gets quoted as a witticism, but the mechanism is plain: interfaces appear wherever communication is required. Two groups who rarely talk will agree on a coarse, formal, rarely-changed contract between their halves; two modules inside one team, where anyone can just shout across the desk, will grow into a tightly coupled blob with a blurred seam. Architecture is not drawn; it precipitates out of communication cost. The best-travelled illustration: four groups assigned to build a compiler tend to produce a four-pass compiler — not because four passes are optimal, but because there were four groups.

The brutal corollary is the book's starting point: you cannot get a loosely coupled system out of a set of tightly entangled teams. However elegant the microservice diagram, if two teams must meet daily to move one feature forward, that boundary will erode. Most failed microservice migrations were not bad technology choices; the team boundaries were never cut to match, and the result is a distributed monolith — separately deployed, still requiring three teams to ship one change.

The remedy the book pushes is the Reverse Conway Maneuver (a term from ThoughtWorks): instead of letting the existing org chart dictate the architecture, decide the target architecture and then reshape teams and communication so that Conway's Law works for you. Note that its power and its precondition are equally large: the move assumes you already know what the target architecture looks like — and on genuinely new problems, that is precisely the thing you are trying to discover. More on this in the objections.

The team is the unit: team APIs and the real cost of reshuffling

"Team-first" is treated as a premise, not a conclusion, and the reasoning is concrete: a freshly assembled team does not start producing. The authors invoke Bruce Tuckman's familiar four stages — forming, storming, norming, performing — and note that reaching the performing stage typically takes weeks to months. So every "let's pull those three people onto the other project" costs far more than three person-months: it knocks both teams back into storming. Hence: keep teams stable, and let the work flow to the team rather than the people flow to the work.

The companion idea is the team API — everything a team exposes to the rest of the organisation. Not just code interfaces, but the services it runs, its documentation and versioning conventions, its ways of working (cadence, on-call), and how to reach it (which channel, what response time). Writing that down is valuable in itself: most cross-team friction is not a technical problem but "I don't know who to ask and I don't know when I'll hear back." A team that cannot state its own API is, from everyone else's point of view, a fog you can only get through by scheduling a meeting.

Cognitive load: the genuinely new contribution

If the book contributed one concept, this is it. Cognitive load comes from the psychologist John Sweller (1988): working memory is limited, and the load during learning splits three ways. The book moves the idea from "one person learning" to "one team operating a system":

• Intrinsic — inherent difficulty of the task: how this language works, how this framework behaves. Reduce it with training, pairing, better tools.
• Extraneous — pure environmental overhead unrelated to the problem: how do I get a machine, how many tickets does a release need, where do the logs go. This should be driven to near zero — which is the entire justification for a platform team.
• Germane — the part that actually creates value: how this business domain really works, what users do in which situations. This is where you want the team's mind to be.

Which yields an alarmingly clear management test: a team's total capacity is fixed, so every unit of extraneous load you add displaces exactly that much of the germane load it had available for understanding the business. "Have them look after that legacy service too" is not a free scheduling question; it is a direct withdrawal from that team's ability to understand its domain.

From this the book derives a rule of thumb for scope: sort domains into simple, complicated (needs specialist knowledge but is solvable) and complex (only understood by experimenting). A team can carry two or three simple domains, but should not carry more than one complicated domain, and a genuinely complex domain usually deserves a dedicated team, sometimes more than one. The authors admit there is no precise measurement; in practice they ask the team directly: "Is the amount you have to hold in your heads overloaded, about right, or is there room?" Crude — but it turns something that was previously only ever grumbled about into a thing you can review on a cadence.

Team size follows: borrowing the anthropologist Robin Dunbar's layers of stable relationships (roughly 5 for a high-trust core, ~15 for a circle of deep mutual trust, ~150 as the outer limit), the book argues for teams of five to nine, and for cutting the groupings above teams at those same magnitudes. Amazon's two-pizza team is the same intuition in a different wrapper.

Four team types — and everything else should be folded in

The famous part. The claim is not "these four are useful" but something stronger: four are sufficient; any team in your organisation that doesn't fit should be reshaped into one of them, because otherwise it is a boundary nobody can state, which is a liability.

The four types and their characteristic failure modes. What a team is is determined by how its output is consumed, not by what it is called.

The clause most often skipped is also the sharpest: a platform must be compelling, not compulsory. The logic is hard-edged — if stream-aligned teams would rather route around your platform and roll their own, your platform is not actually reducing their load, and mandating it merely converts "I can't use this" into "using this hurts and I'm not allowed to say so." Making an internal platform compete for its users the way an external product does is a better test of whether a platform team is real than any org chart.

Three interaction modes — and why the mode must change over time

The second and underrated contribution. Most organisations have drawn the boxes and never specified what kind of line connects them — so every relationship degrades by default into "start a group chat when something comes up." There should be exactly three, and each one should be chosen out loud:

The three modes. The real use of this table is that the same pair of teams should be in different modes at different stages.

Put the two tables together and you get the book's actual method: use collaboration to discover the boundary, and the moment the boundary is understood, switch to X-as-a-Service. That resolves a standing dilemma. Pure collaboration is fast but never grows a clean interface, so teams get progressively more entangled; specifying the interface up front produces an interface that is wrong, which everyone then works around for three years. The right move is to treat collaboration as a survey expedition with an end date, whose deliverable is the interface itself.

Read backwards, this also gives an unusually useful diagnostic: if the collaboration between two teams never manages to end — if every feature still requires both of them in a room — the boundary is wrong, and no amount of collaborating harder will fix it. The authors call the capacity to read such signals organisational sensing: a topology is not a diagram you draw once, it is something that has to keep evolving.

Fracture planes: where should a system be split?

Knowing you must split is not knowing where. The authors borrow the term fracture plane — the plane along which a rock naturally cleaves; strike along it and it opens in one blow, strike across it and you get gravel. The candidate planes in software:

• Business domain boundaries — the most important. This uses the bounded context from domain-driven design: the same word means genuinely different things in different contexts — an "order" is a receivable in billing and a picking slip in the warehouse. A model is consistent only inside its own context; crossing out of it requires translation. Team boundaries should coincide with bounded contexts and must never run through the middle of one.
• Rate of change — something released ten times a day and something touched once a year, owned by one team, will slow the fast half down.
• Compliance and risk — the heavily regulated parts (payments, health data) carry entirely different approval regimes; splitting them spares everything else the heavy process.
• User persona — serving expert users and serving novices are two streams with different rhythms and different standards of judgement.
• Technology and performance isolation — parts needing special hardware, or that must scale independently.
• Location and time zone — a real constraint: two halves ten hours apart cannot sustain collaboration mode and had better be X-as-a-Service.

One criterion runs through all of them: after the split, each team must be able to own one whole thing end to end within a cognitive load it can actually carry. Splitting by technical layer — a front-end group, a back-end group, a DBA group — is the commonest mistake precisely because it inserts three hand-offs into every business flow and leaves no single team able to deliver user value on its own. Every hand-off is a queue, which is why "change the button label" and "rewrite the settlement logic" end up taking suspiciously similar amounts of calendar time. The critique of resource-utilisation thinking lands here too: booking everyone to 100% guarantees that every hand-off waits; flow and utilisation are competing objectives, and most organisations have chosen the second one without noticing.

The Argument in Skeleton

One: accept that Conway's Law cannot be defied. System shape converges on communication structure. You do not get to resist it; you only get to choose whether it shapes you or you use it.

Two: change the optimisation target to fast flow of change. Not headcount utilisation, not cost — how smoothly an idea travels from proposal to production. An organisation at full utilisation is necessarily slow: everyone is booked, so every hand-off queues.

Three: treat the team as indivisible and give it a real capacity ceiling. Long-lived, owning something definite — and how much it can own is set by cognitive load, not by willingness to take on more.

Four: redraw the organisation with the four types. Mostly stream-aligned; a platform that drives extraneous load to zero and has to be a product people would choose; complicated-subsystem teams only where genuine depth demands it; enabling teams aiming at their own obsolescence.

Five: name every line between teams as one of the three modes, and switch as the work matures. Collaborate to find the boundary, X-as-a-Service to lock it in, facilitate to close capability gaps. A collaboration that never ends is a boundary error.

Six: treat all of this as continuous evolution, not a reorg. Cut along fracture planes, watch which seams keep hurting, adjust — the organisation is itself a system requiring continuous refactoring.

Misreadings and Serious Objections

Misreading one: taking it as an org chart to copy. The four boxes are the most screenshot-friendly page in the book, so the usual result is renaming ops "platform team" and architecture "enabling team" while every interaction stays exactly as it was. The authors keep insisting that a team's type is determined by how its output is consumed, not by its label; renaming without changing interaction modes is pure topology theatre.

Misreading two: platform team = infrastructure team. The book's platform is a product: self-service, documented, versioned, with internal customers, and routable-around. A ticket-driven infrastructure group requiring manual approval is not a platform team under this definition; it is an institutionalised source of extraneous load.

Misreading three: stream-aligned means "you build it, you run it," so carry everything yourself. The opposite — the whole platform argument exists so stream-aligned teams need not understand everything. Ownership boundaries should be set by cognitive load, not by a slogan.

The most substantial objection: the evidence base is thin. The framework comes from consulting practice and case studies, not controlled research. The DORA-metric evidence in Accelerate supports the more general claim that small batches, loose coupling and autonomous teams go faster; it does not validate these four types specifically. Which means the book is best used as a vocabulary and a checklist rather than a tested causal model — treat it as a law and it will disappoint.

"Cognitive load" does not survive close inspection as a construct. Sweller's theory concerns an individual's working memory during learning; the book transplants it wholesale onto "a team operating a system," a quite different object, with no measurement method and no rule for aggregation — landing, in the end, on a subjective survey. In fairness: as a thinking tool it is excellent (it converts "we're carrying too much" into a sentence that can be taken seriously) — just don't present it as a quantifiable metric.

The Reverse Conway Maneuver has a chicken-and-egg problem. It requires knowing the target architecture, but in a new domain the architecture is exactly what has to be discovered by building. Academically, the mirroring hypothesis — that organisational structure and system structure reflect each other — has substantial support but is not universal; open-source projects are the standing counterexample, with globally scattered contributors who never meet nonetheless maintaining highly modular systems. Which suggests Conway's Law is really about communication structure rather than reporting structure, and in open source those two have come apart.

Dunbar's number is itself contested — recent replication work has questioned the specific figure. As support for "teams have an upper size limit" it is fine; as a precise threshold it should not be taken literally.

One practitioner complaint is worth recording: the book is short, and the hard part is not in it. Drawing the target topology is the easy step. What is actually hard is reallocating budget, deciding whose team gets dissolved, and justifying a platform team's value to executives who don't read code. You get a map and a vocabulary; you do not get the politics of walking there.

Ten Sentences