Team Topologies
Matthew Skelton & Manuel Pais · 2019
Editorial rating
- Evidence
- 7/10
- Actionability
- 8/10
- Originality
- 9/10
The thesis
How you organize teams determines what software you can build. Conway's Law ("organizations design systems that mirror their communication structure") is not a warning - it's a design tool. Use four fundamental team types and three interaction modes to deliberately shape your architecture and optimize for fast flow of value.
Who this is for
Engineering leaders designing team structures, CTOs dealing with slow delivery caused by unclear ownership, and anyone who's watched a DevOps transformation fail because the org chart didn't change.
My favorite quote
If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.
Why it matters
You can't fight Conway's Law. If your teams are structured poorly, your software will be too - no matter how good your engineers are.
Do this
Draw your current team structure and your software architecture side by side. Where are the mismatches?
Start here
Cognitive load is the real constraint: Every team has a limited capacity to understand and work with complexity. When a team owns too much - too many services, too many dependencies, too many domains - they slow down. The goal isn't to add more people; it's to reduce cognitive load by clarifying ownership and simplifying interfaces. If a team can't hold their domain in their heads, something is wrong.
Critical summary
Skelton and Pais, DevOps consultants, provide a pattern language for organizing software teams. Built on Conway's Law and cognitive load theory, the book offers four team types and three interaction modes as building blocks for org design.
What it gets right
- Conway's Law as design tool, not just observation
- Cognitive load as the key constraint (not headcount)
- Four team types are clear and memorable
- Interaction modes (collaboration, X-as-a-Service, facilitating) clarify expectations
- "Team API" concept - teams as products with defined interfaces
What it misses
- Can feel stretched - core ideas could be conveyed in fewer pages
- Some writing/editing issues frustrate readers
- Interaction mode restrictions feel artificial to some
- Less guidance on how to transition existing orgs to new topologies
- Heavy DevOps/platform focus - less applicable outside software
Evidence blends research (Dunbar's number, cognitive load theory) with case studies from tech companies. Solid but not comprehensive.
Key concepts
Conway's Law
Your software architecture will mirror your org structure. Design both together.
Cognitive Load
The mental effort required to understand and work with a system. Teams have limits.
Stream-Aligned Team
The primary team type - aligned to a flow of work (product, service, user journey). End-to-end ownership.
Enabling Team
Helps stream-aligned teams acquire new capabilities. Coaches, doesn't own.
Platform Team
Provides internal services that reduce cognitive load for stream-aligned teams.
Complicated-Subsystem Team
Owns a domain requiring deep specialist knowledge (e.g., machine learning, video codec).
Team API
Treat your team like a product - define what you offer, how to request it, how to communicate.
Core insights
-
Stream-aligned teams should be the majority
Everything else exists to support them.
-
Platforms are products
If your platform isn't easier than building it yourself, it's failed.
-
Collaboration should be temporary
Long-term collaboration creates dependencies. Aim for X-as-a-Service.
-
Enabling teams work themselves out of a job
They build capability, then move on.
-
Team size matters
Dunbar's number suggests trust breaks down beyond ~150 people. Keep teams 5-9.
-
Architecture and org must co-evolve
Changing software without changing teams (or vice versa) fails.
Implementation steps
Today
- List your teams. Which type are they? (Stream-aligned, enabling, platform, complicated-subsystem)
- Identify one team with too much cognitive load. What could be removed?
This week
- Draw your org structure and software architecture side by side. Where are the mismatches?
- Identify one unclear ownership boundary causing friction
This month
- Define a "Team API" for one team: what do you offer? How should people request it?
- Convert one long-term collaboration into an X-as-a-Service relationship
Ongoing
- When adding features, ask: "Which team owns this end-to-end?"
- Review cognitive load quarterly. Are any teams overwhelmed?
Suggested 30-day practice plan
An editorial application plan created by Monolithic Vault - an interpretation of the book's ideas, not part of the original book.
- Day 1
Categorize all your teams by the four types
- Day 2
Identify stream-aligned teams with unclear ownership
- Day 3
Draw your architecture. Does it match your org structure?
- Day 7
Identify one team with cognitive overload. Plan a reduction.
- Day 14
Create a Team API for one team
- Day 21
Review interaction modes: Where is collaboration creating dependency?
- Day 30
Propose one structural change to improve flow
Free PDF summary
Take this analysis with you: a designed two-page field-notes sheet with the thesis, my favorite quote, the key concepts and core insights, and the full 30-day checklist. Print it or keep it - free, no signup.
Go deeper
If this analysis earned your attention, the full book goes further than any summary can. The original is always the primary source.
