Team Topologies: Organizing Business and Technology Teams for Fast Flow
Team Topologies: Organizing Business and Technology Teams for Fast Flow
Authors: Matthew Skelton & Manuel Pais
Published: 2019
Category: Software Architecture, Team Design, Organizational Effectiveness
Core Thesis
Team structure is a first-class architectural decision. How you organize teams determines what systems you can build. Most organizations randomly assign teams to work, but team topology should be deliberately designed for fast flow of change.
The Four Fundamental Team Types
1. Stream-Aligned Teams
- Aligned to a single, valuable stream of work
- Quick to deliver customer value
- Full stack capabilities within their domain
- Primary team type in most organizations (70-80% of teams)
2. Enabling Teams
- Help stream-aligned teams overcome obstacles
- Research new technologies and practices
- Time-limited assistance, not permanent dependencies
- Example: DevOps evangelists, security champions
3. Complicated-Subsystem Teams
- Handle components requiring specialized knowledge
- Video processing, ML models, complex algorithms
- Reduce cognitive load for stream-aligned teams
- Only use when complexity justifies it
4. Platform Teams
- Provide internal products/services to other teams
- APIs, deployment platforms, monitoring tools
- Treat other teams as customers
- Enable stream-aligned teams to be autonomous
The Three Team Interaction Modes
Collaboration: Two teams work together temporarily on discovery work
X-as-a-Service: One team consumes services from another with minimal collaboration
Facilitating: Enabling team helps stream-aligned team build capability
Key Insights
Conway’s Law is Real
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” Design your team structure to match your desired architecture.
Cognitive Load Management
Teams have limited cognitive capacity. Don’t overload them with:
- Too many domains
- Too many technologies
- Too many responsibilities Minimize cognitive load to maximize flow.
Team Size Matters
- Ideal: 5-9 people (Dunbar’s number applies)
- Smaller than 5: not enough diversity
- Larger than 9: communication overhead explodes
- Keep teams stable for at least 6-12 months
Fast Flow Requires Clear Boundaries
- Minimize hand-offs between teams
- Reduce waiting time and dependencies
- Stream-aligned teams should be long-lived and autonomous
- Each team should own their full value stream
Practical Applications for Staff Engineers
Architecture Decision Records (ADRs)
Document team interaction patterns as architectural decisions. “Payment team will consume Identity service via API (X-as-a-Service mode).”
Team API
Every team should define three APIs:
- Code API: APIs, libraries, services
- Versioning API: How they communicate change
- Communication API: Slack channels, documentation, support hours
Sensing and Evolving Team Structures
- Monitor team cognitive load through surveys
- Track delivery frequency and lead time
- Evolve team boundaries as product evolves
- Split teams when cognitive load exceeds capacity
Anti-Patterns to Avoid
Feature Teams: Teams that cut across multiple products with no clear ownership
Component Teams: Teams organized around technical layers (frontend, backend, DB)
Matrix Management: Reporting to multiple managers kills focus
Ad-hoc Team Formation: Randomly assigning people to projects without considering team dynamics
Key Metrics
- Flow: Time from commit to production
- Team Cognitive Load: Self-reported cognitive load survey
- Dependencies: Number of blocking dependencies per sprint
- Lead Time: Time from idea to customer value
Bottom Line
Most organizations treat team structure as a secondary concern, but it’s primary. You can’t build microservices with monolithic team structures. You can’t achieve fast flow with high-dependency team topologies. Design your team structure first, then build your systems.
Best for: Staff engineers influencing organizational design, engineering leaders restructuring teams, architects planning system boundaries
Implementation time: 6-12 months for meaningful organizational change
ROI: 2-3x improvement in delivery frequency, 50% reduction in lead time (when done correctly)