team-topologies

# Team Topologies

A team-first approach to organization design from Matthew Skelton and Manuel Pais's *Team Topologies*: four fundamental team types, three interaction modes, and deliberate attention to Conway's law and team cognitive load. Use it to structure engineering organizations for fast flow of change — and to keep evolving them as the system, technology, and market shift.

## Core Principle

**The team is the unit of delivery, and organizations ship their communication structure.** Conway's law guarantees that system architecture mirrors how teams actually communicate, so team boundaries and interactions must be designed as deliberately as the software itself. Size each team's responsibilities to its cognitive load, align most teams to streams of business change, declare how teams interact, and treat the resulting topology as a living architecture decision that optimizes for fast flow.

## Scoring

**Goal: 10/10.** Rate org and team designs 0-10 against the principles below. Report the current score and the specific changes needed to reach 10/10.

- **9-10:** Stream-aligned teams own end-to-end slices sized to cognitive load; platform, enabling, and complicated-subsystem teams exist only to reduce that load; interaction modes are explicit and evolve deliberately
- **7-8:** Mostly stream-aligned with a real platform, but some shared ownership, undeclared interaction modes, or one overloaded team
- **5-6:** Team types named but boundaries cut by technology layer; collaboration unbounded; platform adoption mandated
- **3-4:** Component teams everywhere; ticket-driven shared services; every change crosses several teams
- **0-2:** Org ignores Conway's law: project-based staffing churn, "everyone talks to everyone", no notion of cognitive load

## Framework

### 1. Conway's Law and the Inverse Conway Maneuver

**Core concept:** "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure" (Mel Conway). Org communication and system architecture are homomorphic — they mirror each other by force, not by metaphor. The inverse Conway maneuver exploits this: decide the architecture you want, then shape teams and their communication paths so that architecture becomes the natural outcome.

**Why it works:** Teams can only build interfaces they can coordinate, so the space of designs an org can discover is constrained by its communication paths. Reshaping the org reshapes the system; fighting Conway's law instead produces permanent friction and architecture erosion.

**Key insights:**
- Interfaces emerge where teams communicate; seams emerge where they don't — the system records your org's conversations
- The *actual* communication structure (chat, code review, meeting invites) drives architecture, not the org chart
- "Everyone talks to everyone" produces tangled systems: unconstrained communication means unconstrained coupling
- A well-designed org needs *less* inter-team communication, not more — broad cross-team chatter signals wrong boundaries, not healthy collaboration
- Anyone who shapes teams, reporting lines, or hiring is making architecture decisions — architects must co-design the org, and reorgs need architectural review
- When the target architecture and the team structure conflict, the team structure wins

**Applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Target architecture | Shape teams first; expect the architecture to follow | Want decoupled services → small decoupled teams with independent deploys |
| Reorg proposal | Review it as an architecture change | Tech lead/architect signs off on a team merge, not only HR |
| Tangled system | Map actual communication, not the org chart | Chat and review graph reveals hidden coupling between "independent" teams |

### 2. The Four Fundamental Team Types

**Core concept:** Reduce every team to one of four types. Stream-aligned teams own a flow of business change end to end — the primary type, and most teams. Enabling teams grow capabilities in stream-aligned teams and then move on. Complicated-subsystem teams encapsulate deep specialist knowledge (an ML model, a codec, a pricing engine). Platform teams provide a compelling internal product that reduces stream-aligned teams' cognitive load.

**Why it works:** Ambiguous charters ("the API team", "the DevOps team") accumulate work that belongs nowhere and interact unpredictably. Four well-defined types make gaps and overlaps visible, give every team a clear purpose relative to the flow of change, and make the rest of the org's expectations legible.

**Key insights:**
- Stream-aligned is the default; the other three types are justified only by the load they remove from streams
- An enabling team that never disengages has become a dependency — measure it by capabilities transferred, not tickets closed
- Complicated-subsystem teams are justified by genuine specialism, never by managerial convenience — most orgs need zero or one
- A platform is judged by cognitive load removed: if using it is harder than self-hosting, it is a liability with a roadmap
- Anti-patterns: shared-services teams become ticket-queue bottlenecks; a "DevOps team" between dev and ops adds a third silo; component teams everywhere mean every feature crosses many teams

**Applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Ambiguous team charter | Force a choice among the four types | "Core services team" → platform with internal customers and SLAs |
| Deep specialist capability | Complicated-subsystem behind a simple interface | Recommendation-engine team exposes a scoring API to streams |
| New practice rollout | Enabling team, time-boxed | Test-automation specialists coach each stream for 8 weeks, then exit |

See: [references/team-types.md](references/team-types.md)

### 3. The Three Interaction Modes

**Core concept:** Teams interact in exactly three modes: collabor