Team design
Team Topologies is a toolbox, not a target
Four team types and three interaction modes are a useful vocabulary. Redrawing the organisation to match them, book in hand, is how a good idea becomes the next reorganisation. The structure that holds is designed from what the book is built on, not from its diagrams.
What the book gets right
Conway
Structure shapes the system
Teams build what their communication structure allows. Decide the system you want first, then the team boundaries that make it the natural outcome.
Load
A team can only hold so much
A team that owns too many domains, technologies and stakeholders stops owning any of them. Keeping the load bearable is a design decision, not a coaching topic.
Flow
Teams aligned to value, platforms that serve them
A team that owns an outcome end to end, with a platform that removes work instead of adding tickets. That is the shape most organisations are missing.
Where it goes wrong
- Stream-aligned teams are named before any value stream has been mapped.
- Managers gravitate to enabling teams: help without accountability for an outcome. The book says they are temporary; the org chart says otherwise.
- Interaction modes and fracture planes arrive before anyone has agreed what the teams are for.
- The org chart is redrawn to match the four boxes. The dependencies, the funding and the decision rights stay where they were.
- The book drops the words “product team”, and product thinking quietly leaves with them.
The book is easy to read. That is the risk: the map looks complete enough to act on before the territory is understood. Four types and three modes cannot carry the complexity of a real organisation, and were never meant to.
Design from the fundamentals instead
The topologies are a result, not a starting point. Start where the book itself started.
Start with why
Purpose, principles and practices before structure. A team is defined by the problem it solves for a customer, not by its interaction mode.
Follow the domain
Domain-Driven Design gives the real instrument for cognitive load: bounded contexts with a shared language. Team boundaries follow domain boundaries, not the other way round.
Respect Conway and Dunbar
Group the people who need to communicate most, in groups small enough to know each other. Then check what architecture that structure will produce.
Treat it as complex
Organisations are a complex domain in Cynefin terms: probe, sense, respond. No big design up front, however tidy the diagram. Change the structure in steps and measure the flow after each.
Two transformations, one lesson
Big transformation, small impact
The framework arrived before the why
A large organisation, external experts facilitating, the full vocabulary introduced at once. The discussions advanced; the structure did not. Months later there was still no map of which teams existed, what they owned or how they interacted.
Small transformation, big impact
The why arrived before the boxes
A midsize rail scale-up: ten technology teams and eleven chapters managing each other’s dependencies. A Start with Why, then domain and Conway, then the structure: three customer-facing product teams, two platform teams, one platform and enabling team, four chapters. No capacity lost, higher throughput. The case →
The longer version of this argument, with the sources: Stop Team Topologies, on Medium →
Questions clients ask
So we should not read Team Topologies?
Read it. Put it in the toolbox next to Conway, Dunbar, Domain-Driven Design and Cynefin. Then design for your organisation and let the structure evolve, instead of installing the book.
How do we manage cognitive load without the four types?
Through domain boundaries. A team with one bounded context and one shared language carries less load than any team type can give it. Platforms then take away the work that is the same for everyone.
We already restructured. Now what?
Map the value streams and the domains the new teams actually own, and compare with the chart. Where they differ, the chart loses. That comparison is where an audit usually starts.
Redrawing the team structure?
Before the boxes move, look at the domain, the flow and the why. One conversation tells whether the design will hold.