Team Topologies
Main Argument
Teams, not individuals, are the fundamental unit of software delivery, and team structure should be designed deliberately to enable fast flow of change. Because organizations produce systems that mirror their communication structure (Conway's Law), shaping teams and their interactions is a way to shape the architecture. The key constraint is cognitive load: a team should own no more than it can comprehend, and the whole organization can be expressed with four team types and three interaction modes.
Key Takeaways
- Conway's Law couples architecture to org structure; the Inverse Conway Maneuver uses team design to produce a target architecture.
- Cognitive load is the primary constraint on how much a team can own; exceeding it destroys flow.
- The team is the unit of delivery: small, long-lived, stable, with clear ownership.
- Four fundamental team types: stream-aligned (the default), platform, enabling, complicated-subsystem. The latter three exist to support fast flow for stream-aligned teams.
- Three interaction modes: collaboration, x-as-a-service, facilitating. Each should be a deliberate, often time-bounded choice.
- Every team has an API (code, docs, ways of working, expectations); interact through it.
- Split systems along fracture planes (domain, change cadence, risk) so parts are loosely coupled and single-team ownable.