topologies aren't permanent
a team topology is a snapshot. business changes, products mature, capabilities spread or concentrate — and the shape of the org has to move with them. the mistake isn't picking the 'wrong' topology; it's treating any topology as permanent. evolution is the default case, not the exception.
this lesson is about moving teams between types — when, how, and what to watch for.
the five transitions that actually happen
- stream-aligned → split into two stream-aligned the team got too big, too loaded, or started owning two coherent flows. the move is along a fracture plane: a boundary where each half can work for weeks without syncing. done well, both halves retain full end-to-end ownership of their slice.
- stream-aligned → platform (extraction) some capability the team built — ci tooling, a shared library, an ops dashboard — turns out to be needed by several other teams. the choice: either invest in making it a real platform product, or kill it and let consumers build their own. hybrid 'informal platform' arrangements almost always drift into fake-platform.
- complicated-subsystem → platform a specialist team's output stabilises, its interface matures, and consumers grow. at some threshold it becomes a platform team — the work isn't specialist anymore, it's productised. keep the name if it helps; change the operating model.
- enabling → end, or rotate enabling teams finish engagements. when they do, they either move to the next team that needs the capability, or they disband. the failure mode is drift into permanent attachment — always from an individual coach deciding it's easier to do the work than teach it one more time.
- any type → disbanded teams end. a product sunsets, a capability is no longer strategic, a merger removes a reason to exist. disbanding well — redistributing people, archiving knowledge, owning the handover — is a skill that most orgs are bad at and that pays for itself every time.
changing mode more often than type
most evolution isn't a type change; it's a mode change. the same platform team collaborates with a new consumer, then facilitates their onboarding, then settles into x-as-a-service. the same complicated-subsystem team collaborates with one team on an extension, then returns to x-as-a-service for everyone else. mode is cheaper to change than type; use it first.
pick the right move
five transitions
each scenario is a team whose situation is pushing it to change. what's the cleanest move?
the discipline of writing it down
the thing most orgs don't do — and team topologies quietly insists on — is maintaining a team api: a one-page document per team stating its type, purpose, owned surfaces, interaction modes with neighbouring teams, and runbook for being reached. when a team evolves, the team api is the first thing to change. when a team api and the real behaviour diverge, the divergence is the first thing to fix.
the format doesn't matter. the habit does. a topology you maintain deliberately is a topology you can evolve; a topology you drew once and stopped looking at is already wrong.
that's the course
seven lessons, one framework. four types, three modes, cognitive load as a constraint, Conway's law running underneath everything. the book is longer and has more examples; most of what's there is elaboration on these primitives. the test you'll keep using is the same every time: is this team's type clear, is its interaction mode with its neighbours clear, and does that match its actual behaviour? if yes, you have a topology. if no, you have a reorg coming.