Team Topologies

1The org chart lies about who actually talks to whom

Every organization has three structures at once:

• the formal one (the org chart, for compliance);
• the informal one (who has influence);
• the value-creation one (how the work really gets done, person to person).

The org chart only photographs the first, yet we keep using it to assign work. The book's older joke nails it: "if you have four groups working on a compiler, you'll get a four-pass compiler" (Eric Raymond, ch. 1).

And the real bottleneck hiding under the chart is cognitive load: the book opens on a team of eight at OutSystems covering CI, CD, infrastructure and test execution at once, jacks of all trades, masters of none, motivation quietly collapsing under the context-switching (ch. 1).

2Conway's law, and the maneuver that turns it around

Conway's law (1968) says a system's design is forced to copy the communication structure of the organization that builds it. Ruth Malan's sharpening is the line to remember: "if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins" (ch. 2).

Instead of fighting that force, the book flips it: the Reverse Conway Maneuver means you shape the teams first to get the architecture you want. Want four independent services instead of four apps glued to one shared database? Stop sharing a central DBA and put the database skill inside each team. Adidas did exactly this kind of redesign and multiplied its release frequency sixtyfold (ch. 2).

And the counter-intuitive corollary: more communication isn't better, two teams talking constantly when the design says they shouldn't is a smell, not a virtue.

3The team is the unit of delivery, and cognitive load is its budget

Stop assigning work to individuals. The book's unit is "a stable grouping of five to nine people who work toward a shared goal as a unit" (ch. 3), long-lived (it takes weeks to gel), and owning its area outright: "every part of the software system needs to be owned by exactly one team." Breaking up a team that works is, in Allan Kelly's words quoted as the chapter's epigraph, "corporate psychopathy" (ch. 3).

And the team's real budget isn't headcount, it's cognitive load, which the book splits three ways:

• intrinsic: the inherent difficulty of the problem, minimize it through training;
• extraneous: how to redeploy, how to configure, pure noise, eliminate it through automation;
• germane: the business domain that deserves attention, maximize it.

The practical move: size each team's slice of the system to fit what it can actually hold in its head, and publish a "Team API", the code, docs, and channels other teams need to interact with you without booking a meeting.

4Four team types are enough, not thirty

Most orgs accumulate team types like sediment: infra, ops, tooling, middleware, QA, DBA, "the DevOps team". The book collapses all of it into four, which act like magnets every team should converge toward:

• Stream-aligned: aligned to one flow of value (a product, a journey), ships end to end with no hand-off, and should be the vast majority, "the ratio of stream-aligned teams to other kinds of teams should be between about 6:1 and 9:1" (ch. 5).
• Enabling: specialists who help a stream team pick up a missing capability, then leave, they aim for their own obsolescence.
• Complicated-subsystem: a rare team for a part so specialized it needs experts (a video codec, a pricing engine), created to lower others' cognitive load, not because a component is shared.
• Platform: provides internal self-service so stream teams don't have to master the whole stack, and it must be "just big enough", the Thinnest Viable Platform, because developers left alone build a bigger platform than anyone needs.

5Three ways for teams to interact, and no more

Having the right teams isn't enough; you have to define how they touch. The book allows exactly three modes:

• Collaboration: two teams work closely for a bounded time with shared responsibility, great for discovering new ground (cloud plus embedded, say), but expensive, you carry the other team's context in your head, so a team collaborates with only one other at a time.
• X-as-a-Service: one team consumes what another provides (an API, a platform) with minimal friction and no daily coordination, predictable delivery once the boundary is clean, at the cost of slower innovation across that line.
• Facilitating: one team helps another clear blockers and learn, the default mode of enabling teams.

The sharp test that follows: any interaction that isn't one of these three is waste, and a sign your team boundaries are drawn in the wrong place.

6Where to cut a system: find its fracture planes

If a team is to own its slice without constantly tripping over others, the system has to be cut along natural seams. The book calls them fracture planes: "a natural seam in the software system that allows it to be split easily into two or more parts" (ch. 6), like a stonemason striking marble where it wants to break.

The default seam is the business domain (the DDD bounded context): a music service splits cleanly into discovery, delivery and licensing. Other seams when needed: regulatory scope (keep the PCI-DSS part separate so its rules don't infect the rest), change cadence, risk, performance.

The practical test for whether your split is good: take your next real feature and count how many teams must coordinate to ship it. One = the seam is in the right place. Three = you cut across a domain, not along it. (Same test as for microservices in the Clean Architecture note.)

And the trap to avoid above all is the distributed monolith, the worst of both worlds: "if you have microservices but you wait and do end-to-end testing of a combination of them before a release, what you have is a distributed monolith" (Amy Phillips, ch. 6). Splitting the code without splitting the deployment buys you the cost of microservices and none of the autonomy.

7Nothing is fixed, and the framework alone isn't enough

Topologies aren't a fixed state; they evolve on triggers the book names: the software outgrows a single team (you've crossed Dunbar's ~15), delivery slows down, or too many services pile onto a shared foundation that should become a platform. The clearest trigger is visible to the naked eye: your stand-up runs past fifteen people and drags on because half of them only listen for their own part. That's Dunbar's signal: the team has outgrown the size where everyone holds everyone else's context. You split. Stable teams with clear communication paths become the organization's sense organs, the way it feels the market and steers itself.

And the book closes with a rare honesty: "Team Topologies alone will not produce an effective software-delivery and operations organization" (Conclusion). It still needs a healthy culture, solid engineering practices (continuous delivery, test-first, operability), sane finance, and a clear business vision. The structure is the planting plan; without good soil, water and light, even the best plan grows nothing. One team summed up the whole spirit: "we used Kubernetes because we wanted to change our organization", not the other way around (uSwitch, ch. 8).