Team Topologies

---
name: team-topologies
description: 'Organize business and technology teams for fast flow using Skelton & Pais''s "Team Topologies". Use when the user mentions "team topologies", "Conway''s law", "platform team", "stream-aligned team", "team boundaries", "cognitive load", "how should we split teams", "who owns this service", "team dependencies", or "reorg". Also trigger when reorganizing engineering teams, aligning team and service boundaries, splitting a monolith and deciding ownership, reducing cross-team handoffs, or designing an internal platform. Covers the four team types, three interaction modes, the inverse Conway maneuver, and fracture planes. For bounded contexts, see domain-driven-design. For dependency direction in code, see clean-architecture.'
license: MIT
metadata:
  author: wondelai
  version: "1.2.0"
---

# 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… install to load the full skill