Team Topologies
Four team types and three interaction modes, used deliberately to shape both the organisation and the architecture it produces.
Definition
Four fundamental team types:
- Stream-aligned — owns a flow of work for a business domain, end to end. The default; most teams should be this.
- Platform — provides self-service internal products that reduce the cognitive load on stream-aligned teams.
- Enabling — helps other teams acquire a capability, then leaves. Explicitly temporary.
- Complicated-subsystem — owns something requiring deep specialist knowledge (a pricing engine, a video codec, a risk model). Used sparingly.
And three interaction modes: collaboration (high bandwidth, temporary, for discovery), X-as-a-service (low bandwidth, ongoing, the goal for most interactions), and facilitating (one team helping another for a period).
The idea that does the work: cognitive load
A team can only hold so much. Exceeding it produces shallow understanding, slow incident response, and systems that are maintained rather than improved.
Architecture should therefore be shaped so that each team's domain fits within its cognitive capacity. That is a genuinely different design criterion from the usual technical ones, and it explains several otherwise-puzzling decisions — such as merging services to reduce the number a team must reason about.
Cognitive load is also what makes platform teams necessary rather than optional: their purpose is to remove infrastructure load from stream-aligned teams so those teams can spend their capacity on the domain.
The interaction mode as a design tool
Most interactions should be X-as-a-service: one team consumes another's capability through a well-defined interface without needing to talk. Frequent collaboration between two teams is a signal — either the boundary is wrong, or they should be one team.
Collaboration is deliberately temporary. Two teams collaborating indefinitely is not a healthy steady state; it is a boundary that has not been resolved.
What is commonly got wrong
- Every team called stream-aligned, with no platform investment, so each solves infrastructure independently.
- Platform teams that take requests rather than providing self-service — a service desk with a new name, preserving the handoff they were meant to remove.
- Enabling teams that never leave, becoming permanent dependencies.
- Too many complicated-subsystem teams, used to justify specialism rather than reflecting genuine depth.
- The model adopted as a reorganisation exercise without changing interaction modes or architecture, which changes nothing.
Interview question
"When should a capability be a platform team rather than part of a stream-aligned team?"