One-page summary · 2 min read
Team Topologies
Organizing Business and Technology Teams for Fast Flow
by Matthew Skelton, Manuel Pais
The big idea
Organizations should deliberately design their team structures -- not just their processes -- around fast flow of value, because the shape of your teams will eventually determine the shape of your software whether you plan it or not.
Skelton and Pais argue nearly every team should map to one of four types. Stream-aligned teams own a slice of business value end-to-end with no handoffs. Platform teams build internal, self-service capabilities that let stream-aligned teams move faster. Enabling teams are temporary specialists who help other teams close a capability gap and then move on. Complicated-subsystem teams handle a component that genuinely requires deep specialist knowledge. Teams interact only through three modes -- collaboration, X-as-a-service, and facilitation -- chosen deliberately and revisited over time.
Reviewers, including engineer Jacob Kaplan-Moss, have pushed back on the claim that these are the only four team types an organization ever needs, calling some edge cases a stretch to categorize; the framework is easiest to apply in mid-size-to-large software organizations.
Key ideas
Conway's Law as a design input, not just an observation
The book treats Conway's original observation as something leaders should actively exploit, deliberately shaping teams to produce the software architecture they want.
Cognitive load as a team-sizing constraint
A team's scope should be bounded by what its members can hold in their heads at once; overloading a team with too many unrelated systems is a primary cause of slow delivery.
Team API
Each team is framed as exposing a team API -- the interfaces, documentation, and practices other teams use to interact with it.
Thinnest viable platform
Platform teams are advised to build the smallest platform that removes friction for stream-aligned teams, avoiding an over-engineered internal platform that becomes its own bottleneck.
Interaction modes have a lifecycle
Collaboration mode is meant to be temporary and high-bandwidth, X-as-a-service the default steady state, with teams consciously transitioning between them.
Reverse Conway maneuver
The book advises deliberately restructuring teams first, before a desired architecture change, since architecture tends to converge to match team boundaries.
Try it this week
- Categorize your current teams against the four topologies and flag any team that doesn't cleanly fit one.
- Write down your team's team API -- the concrete ways other teams should engage with you -- and share it with one adjacent team this week.
- Audit your current cross-team dependencies and label each relationship as collaboration, X-as-a-service, or facilitation.
- If you're planning an architecture change, sketch the team structure that would naturally produce that architecture and consider making that org change first.
Is it for you?
Best for
- Engineering directors and VPs restructuring a growing organization who need a shared vocabulary for team boundaries and hand-off points.
- Platform and DevOps leaders trying to justify or scope an internal platform team without over-building it.
Less useful if
- Individual contributors or first-time managers without organizational design authority.
- Small startups or single-team organizations, where the four-topology distinction adds overhead rather than clarity.