Part 7 · 1 chapters · ~8 min
Team Topologies
Teams as the unit of delivery, cognitive load as the limit on ownership, the four team types, the three interaction modes, Conway's law used deliberately, and platforms as products, with common organisational questions answered and the renaming misuse.
9
Team Topologies
The Infrastructure course part 6 applies this book directly. Here is what to take from the source.
| question in your organisation | Team Topologies answer |
|---|---|
| should frontend be its own team? | usually not: put frontend engineers in stream-aligned teams; a design-system platform team serves them |
| who owns the shared payments SDK? | a platform or complicated-subsystem team, consumed as a service with an API and SLOs |
| how do we roll out accessibility practice? | an enabling team that facilitates, time-boxed, then steps back |
| two teams keep blocking each other | wrong interaction mode or wrong boundary: collaborate briefly to redraw it |
| one team owns nine services | cognitive load: split by domain |
where it has aged
It has not aged much. The usual misuse is renaming existing teams with the four type names without changing what they own or how they interact. The value is in cognitive load and the interaction modes, not in the labels.
TEAM TOPOLOGIES
Matthew Skelton and Manuel Pais, 2019: team types, interaction modes and cognitive load
swipe the figure sideways, or tap expand for full screen
1/6
Teams are the unit of delivery
Teams as the unit: long-lived teams that stay together build trust and context; work flows to teams rather than people being shuffled to work. Team size around 5 to 9; groupings of teams (tribes, groups) bounded at roughly 50 and 150 people.