Short answer
Structure engineering around the flow of business value. Most engineers should sit in small, long-lived stream-aligned teams that own a product area end to end. Add a platform team when teams repeat the same infrastructure work, enabling teams to spread new skills, and a complicated-subsystem team only for deep specialist parts. Keep each team’s cognitive load manageable.
- 4 - team types: stream-aligned, platform, enabling, complicated subsystem
- 3 - ways teams interact: collaboration, X-as-a-Service, facilitation
- 5–9 - people per team, a common size for shared context and ownership
- 1 - clear owner for every service, incident and roadmap
The best way to structure engineering teams as you scale is around the flow of business value, not around technologies or job titles. The Team Topologies model gives leaders a shared vocabulary for this: four team types and three ways for teams to work together. It helps you grow from one team to dozens without every feature needing five hand-offs.
Why structure becomes the bottleneck
At ten engineers, one team can hold the whole system in its head. At fifty, the organisation chart starts to shape the software: if a feature needs the front-end team, the API team, the database team and operations, every release becomes a negotiation. Lead time grows, ownership of incidents blurs and good engineers spend their week in coordination meetings.
The fix is not more process. It is drawing team boundaries so that most work can be finished inside one team, and making the interfaces between teams deliberate. The same principle applies across borders, as we describe in scaling innovation across borders.
The four team types
Team typeWhat it doesWhen you need itStream-alignedOwns a flow of business work end to end: build, run and improveAlways: most engineers should be herePlatformProvides internal services as a product, such as deployment, observability and dataWhen several teams repeat the same infrastructure workEnablingHelps other teams adopt new skills or tools, then steps backDuring a shift, such as a cloud migration or AI adoptionComplicated subsystemOwns a part needing deep specialist expertiseFor genuinely hard domains: pricing engines, video, ML models
A common mistake is creating many component teams (“the database team”, “the front-end team”). Each looks efficient in isolation but forces every feature across several queues. Stream-aligned teams own the full slice instead.
Three ways teams should interact
- Collaboration: two teams work closely for a defined period to discover something new. Valuable, but expensive, so time-box it.
- X-as-a-Service: one team consumes what another provides with minimal coordination, like using an internal deployment platform. This is the default you want for mature capabilities.
- Facilitation: one team coaches another to build a skill, then withdraws. Typical for enabling teams.
Writing down which mode each pair of teams uses removes a surprising amount of friction. If a team believes it is “collaborating” while the other thinks it is providing a service, expectations clash.
Cognitive load: the limit leaders forget
Every team can only handle so much complexity. If one team owns too many services, technologies or domains, it slows down, makes poorer decisions and stops improving its own systems. When a team is overloaded, split the domain or move undifferentiated work to a platform; do not simply add people to the same team.
A practical reorganisation plan
Run the change in phases, starting with one product area. An architecture review often helps, because team boundaries and service boundaries should line up.
Questions to ask your engineering leaders
Is our structure helping or hurting delivery?
- How many teams are involved in shipping a typical feature, and where does work wait?
- Does every service and incident have exactly one owning team?
- Which teams are overloaded, and what will we move off their plate?
- Which repeated work should become a self-service platform capability?
- How does our team map line up with our architecture?
Engineering leadership
Planning a reorganisation or scaling fast?
We map your value streams, team boundaries and architecture, and design a phased structure that shortens lead time without disrupting delivery.
Sources
- Team Topologies key concepts (teamtopologies.com)
Originally published at phpscientist.com.
Top comments (0)