Decision guide
Team Structures: Stream-Aligned vs Component vs Platform Teams
How should you organise engineering teams?
Side by side
| Criterion | Stream-aligned teams | Component / layer teams | Platform team | Enabling team |
|---|---|---|---|---|
| Hand-offs per feature | Few | Many | Self-service when mature | Temporary |
| Cognitive load | Bounded by domain | Narrow but coordination-heavy | High in its area; design APIs well | Broad, short engagements |
| Interaction mode (Team Topologies) | Consumes platforms as a service | Constant collaboration | X-as-a-Service | Facilitating |
| Good default? | Yes, for most teams | Rarely | Once 3+ teams need it | Situational |
When to choose each
Stream-aligned teams
Each team owns a flow of work (a customer journey or domain) end to end.
Choose when
- You want most features delivered by one team
- Domains can be separated with clear boundaries
Avoid when
- Every team would need rare specialist skills (add enabling or subsystem teams)
Component / layer teams
Teams own technical layers or components (frontend, backend, database).
Choose when
- A component is genuinely shared and complex
- Very small organisations where one team does everything
Avoid when
- Most features need several teams
- Lead time is dominated by hand-offs
Platform team
Provides internal products (deploy, observability, data infrastructure) consumed as a service.
Choose when
- Several stream-aligned teams need the same capabilities
- Self-service would remove repeated requests
Avoid when
- It becomes a ticket queue instead of a product
- There are too few consumers to justify it
Enabling team
Temporarily helps other teams adopt a capability or practice, then moves on.
Choose when
- Teams need to learn a new capability (e.g. observability, security practices)
- Expertise is scarce
Avoid when
- It becomes a permanent dependency
Verdict
Make most teams stream-aligned, add a platform team once several teams need shared capabilities, and use enabling or complicated-subsystem teams only where needed. Avoid component/layer teams for product work — by Conway's law they produce hand-off-heavy systems.