# 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

- [[Methodologies/Agile-Principles]] — Agile frameworks and team practices
- [[Methodologies/Engineering-Culture]] — Blameless culture, psychological safety
- [[Architecture/Domain-Driven-Design]] — Bounded contexts align with stream-aligned teams
- [[Architecture/Architectural-Styles]] — Modular monolith vs microservices team mapping
- [[DevOps/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)*