# Team Topologies — Structuring Teams for Fast Flow

<!-- hint:slides topic="Team topologies: Conway's Law, four team types (stream-aligned, enabling, complicated-subsystem, platform), interaction modes, and cognitive load" slides="6" -->

## Conway's Law

**"Organizations design systems that mirror their communication structure."** — Melvin Conway (1967)

If you have three teams working on a system, you'll get a three-part system. If teams don't talk to each other, the architecture will have hard boundaries where they don't. Conway's Law isn't a suggestion—it's an observation of how organizations actually work. The implication: **change the team structure to change the system architecture.**

## The Four Fundamental Team Types

From *Team Topologies* by Skelton & Pais:

```mermaid
flowchart TB
    subgraph TeamTypes[Four Team Types]
        SA[Stream-Aligned]
        P[Platform]
        E[Enabling]
        CS[Complicated-Subsystem]
    end
    subgraph Modes[Interaction Modes]
        Collab[Collaboration]
        XaaS[X-as-a-Service]
        Facil[Facilitating]
    end
    SA -->|XaaS| P
    E -->|Facil| SA
    CS -->|Collab| SA
```

```mermaid
flowchart TB
    subgraph Types["Four Team Types"]
        SA[Stream-Aligned Team]
        P[Platform Team]
        E[Enabling Team]
        CS[Complicated-Subsystem Team]
    end

    SA -->|"owns full stream"| P
    P -->|"provides platform"| SA
    E -->|"helps learn"| SA
    CS -->|"owns complex domain"| SA
```

| Type | Purpose | Example |
|------|---------|---------|
| **Stream-aligned** | Own a full stream of value (e.g., checkout, search). They build, run, and evolve it. | "Checkout team" owns checkout end-to-end |
| **Platform** | Provide internal services, APIs, tooling so stream-aligned teams can ship without reinventing the wheel. | Platform team provides auth, deploy pipelines, observability |
| **Enabling** | Help stream-aligned teams learn new skills or adopt new tech. Temporary; they enable then step back. | Enable team helps adopt Kubernetes |
| **Complicated-subsystem** | Own a highly specialized domain (e.g., ML model, cryptography) that requires deep expertise. | Team owns payment compliance and PCI |

**Stream-aligned teams are the default.** Platform, enabling, and complicated-subsystem teams exist to *support* them.

## The Three Interaction Modes

How teams work together matters as much as team type:

```mermaid
flowchart LR
    subgraph Modes["Interaction Modes"]
        C[Collaboration]
        X[X-as-a-Service]
        F[Facilitating]
    end

    C -->|"high trust, discover together"| X
    X -->|"clear API, SLA"| F
    F -->|"teach, then step back"| C
```

| Mode | When to Use | What It Looks Like |
|------|-------------|-------------------|
| **Collaboration** | Discovery, new domain, high ambiguity | Two teams work side-by-side; shared goals; flexible boundaries |
| **X-as-a-Service** | Stable, well-defined interface | Platform team provides a service; stream-aligned team consumes via API/SLA; low touch |
| **Facilitating** | Learning, adoption, transition | Enabling team teaches and supports; stream-aligned team learns; enabling steps back when done |

**Default to X-as-a-Service** for platform teams. Collaboration is expensive—use it when discovery is needed. Facilitating is time-bound.

## Cognitive Load: The Key Constraint

Teams can only hold so much in their heads. **Cognitive load** has three dimensions:

1. **Intrinsic** — inherent complexity of the domain (e.g., payments is hard)
2. **Extraneous** — unnecessary complexity from tooling, process, unclear ownership
3. **Germane** — productive learning that improves the team over time

**Goal:** Minimize extraneous, manage intrinsic, maximize germane. If a team's cognitive load is too high, they'll cut corners, create tech debt, or burn out. Splitting a team or adding a platform team can *reduce* load by simplifying what each team must understand.

## Team Size: Two-Pizza Rule and Dunbar

- **Two-pizza rule** (Amazon): Team should be feedable by two pizzas—roughly 5–9 people. Larger teams need more coordination.
- **Dunbar's number:** Humans can maintain ~150 meaningful relationships, but effective *working* teams are typically 7±2. Beyond that, sub-teams form informally—design for it explicitly.

**When to split:** When cognitive load is too high, when wait times for decisions grow, or when the team naturally divides into sub-domains.

## Team APIs

Teams interact through **APIs**—not just HTTP, but contracts: "We provide X; you consume Y; here's the SLA." A team API includes:

- **Documentation** — What we offer, how to use it
- **SLA** — Uptime, latency, support
- **Versioning** — How we evolve without breaking consumers
- **Support** — Who to ask, how to escalate

Platform teams should have clear team APIs so stream-aligned teams can self-serve.

## Evolving Team Structures

Team topologies aren't static. As the product and organization evolve:

- **Early stage:** Few stream-aligned teams; maybe one platform person
- **Growth:** Add platform team when stream-aligned teams duplicate work
- **Scale:** Add enabling teams for big transitions (e.g., cloud migration)
- **Mature:** Complicated-subsystem teams when a domain requires dedicated expertise

**Avoid the Inverse Conway Maneuver pitfall:** Don't reorganize to "match" a desired architecture without also changing communication and incentives. Structure and behavior must align.

## Common Pitfalls

| Pitfall | What Goes Wrong | Better Approach |
|---------|-----------------|-----------------|
| **Too many collaboration modes** | Everyone needs to work with everyone; meetings explode | Default to X-as-a-Service; limit collaboration to true discovery |
| **Platform team does project work** | Platform becomes a bottleneck; stream-aligned teams wait | Platform provides capabilities; stream-aligned teams build features |
| **Enabling never steps back** | Enabling team becomes permanent; stream-aligned doesn't own | Enabling has an exit criteria; handoff and step back |
| **Ignoring cognitive load** | Teams are overwhelmed; quality drops | Split teams or add platform; simplify ownership |
| **Reorg without behavior change** | New org chart, same silos | Change incentives, APIs, and communication patterns |

## Four Team Types — Visual Summary

```mermaid
flowchart TB
    subgraph StreamAligned["Stream-Aligned (default)"]
        SA1[Own full stream]
        SA2[Build, run, evolve]
    end

    subgraph Platform["Platform"]
        P1[Internal services, APIs]
        P2[X-as-a-Service to streams]
    end

    subgraph Enabling["Enabling"]
        E1[Teach, support]
        E2[Step back when done]
    end

    subgraph Complicated["Complicated-Subsystem"]
        C1[Specialized domain]
        C2[Deep expertise required]
    end

    Platform --> StreamAligned
    Enabling --> StreamAligned
    Complicated --> StreamAligned
```

## Key Takeaways

1. **Conway's Law** — Structure and architecture are linked; change one to change the other.
2. **Stream-aligned first** — Default team type; others support them.
3. **Interaction modes** — Collaboration (discovery), X-as-a-Service (default), Facilitating (learning).
4. **Cognitive load** — The key constraint; design to reduce it.
5. **Team APIs** — Clear contracts between teams enable autonomy.