Team Topologies
Organizational design for fast flow. Team structure should match architecture (Conway's Law in reverse).
Four Fundamental Team Types
| Team Type | Purpose | Key Characteristics |
|---|---|---|
| Stream-aligned | Deliver value to customers | Own a product/service end-to-end; aligned to business domain; long-lived |
| Enabling | Help other teams build capabilities | Coaching, upskilling, removing blockers; temporary engagement |
| Complicated-Subsystem | Build/maintain complex components | Deep expertise; narrow focus; mathematical/algorithmic/technical complexity |
| Platform | Provide self-service infrastructure | Reduce cognitive load for stream-aligned teams; product mindset; "platform as product" |
Team Interaction Modes
| Mode | Description | When to Use |
|---|---|---|
| Collaboration | Work closely together on shared goal | High uncertainty, discovery, innovation |
| X-as-a-Service | One team provides service to another | Clear, stable interface; low uncertainty |
| Facilitating | One team helps another improve | Capability building, knowledge transfer |
Default: X-as-a-Service for Platform → Stream-aligned; Collaboration for Enabling → Stream-aligned.
Conway's Law (Applied)
"Organizations which design systems are constrained to produce designs whose structures are copies of the communication structures of these organizations."
Inverse: Design your team structure to produce the architecture you want.
Anti-Pattern: Component Teams
Frontend Team Backend Team Database Team Ops Team
│ │ │ │
└───────────────┼───────────────┼─────────────┘
▼
"Feature" requires
coordination across
4 teams = slow
Pattern: Stream-Aligned Teams
┌─────────────────────────────────────────────┐
│ Order Management Team │
│ (Frontend + Backend + DB + Ops for Orders) │
└─────────────────────────────────────────────┘
- Own full vertical slice
- Deploy independently
- Minimize cross-team dependencies
Cognitive Load
Team cognitive load = How much a team must hold in working memory to do their job.
Three Types
| Type | Source | Mitigation |
|---|---|---|
| Intrinsic | Domain complexity | Domain modeling, ubiquitous language, bounded contexts |
| Extraneous | Bad tools, processes, unclear docs | Good tooling, automation, clear docs, platform |
| Germane | Learning, problem-solving | Pairing, mobbing, enabling teams, slack time |
Goal: Maximize germane; minimize extraneous; manage intrinsic via domain design.
Platform Engineering
Platform = Product for internal developers
Platform Principles
- Self-service — Teams consume via API/UI without ticket queues
- Product mindset — Platform has a backlog, roadmap, PM, users (developers)
- Reduce cognitive load — Abstract complexity; provide golden paths
- Measure developer experience — Lead time, deployment frequency, satisfaction
Platform Capabilities (Examples)
| Capability | Reduces |
|---|---|
| CI/CD templates | Pipeline boilerplate |
| Service mesh / API gateway | Networking complexity |
| Observability stack | Monitoring setup |
| Deployment automation | Release toil |
| Secrets management | Security complexity |
| Local dev environments | "Works on my machine" |
Platform Anti-Patterns
- Platform as shared services team — Ticket-driven, not self-service
- Building everything — Focus on highest leverage; buy commodity
- No product management — Platform needs a PM to prioritize
- Ignoring adoption — Measure usage; iterate based on feedback
Evolution of Team Structure
Startup (1-2 teams)
- Single stream-aligned team (full stack)
- No platform team needed yet
Growth (3-8 teams)
- Multiple stream-aligned teams by business domain
- First platform team emerges (shared tooling, CI/CD)
- Enabling team for practices (TDD, DDD, architecture)
Scale (8+ teams)
- Clear bounded contexts = stream-aligned teams
- Dedicated platform team(s)
- Enabling teams for specific capabilities (security, data, ML)
- Complicated-subsystem for genuine complexity (e.g., pricing engine, ML platform)
Sensing Team Health
Leading Indicators
| Signal | Healthy | Unhealthy |
|---|---|---|
| Lead time | Hours to days | Weeks |
| Deployment frequency | Multiple/day | Monthly |
| Change failure rate | <15% | >30% |
| MTTR | Minutes/hours | Days |
| Team satisfaction | High (eNPS > 30) | Low |
| Cross-team dependencies | Few, managed | Many, blocking |
Team Topology Review
Quarterly: "Does our team structure still serve our architecture and flow?"
Related Notes
- Agile Principles — Agile frameworks and team practices
- Engineering Culture — Blameless culture, psychological safety
- Domain Driven Design — Bounded contexts align with stream-aligned teams
- Architectural Styles — Modular monolith vs microservices team mapping
- CI CD Best Practices — Platform provides pipeline templates
Sources: Team Topologies (Matthew Skelton & Manuel Pais), DevOps Topologies, Conway's Law, Cognitive Load Theory, Google SRE (Platform Engineering), AWS Well-Architected (Team Topologies)