team-topologies

---
name: team-topologies
description: Use when organizing engineering/business teams for fast flow: Conway's law, stream-aligned vs platform vs enabling vs complicated-subsystem teams, interaction modes, cognitive load, or a reorg.
category: Business Knowledge
version: 1.0.0
tools: []
---

# Team Topologies

A team-first approach to organization design: 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, evolving the topology 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 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; 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.

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

"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 metaphor. The inverse Conway maneuver exploits this: decide the target architecture, then shape teams and communication paths so that architecture becomes the natural outcome.

Key insights: interfaces emerge where teams communicate, seams emerge where they don't — the system records the org's conversations. 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 — reorgs need architectural review. When target architecture and team structure conflict, the team structure wins.

Apply: want decoupled services → shape small decoupled teams with independent deploys first. A reorg proposal should get architectural sign-off, not just HR approval. A tangled system should be diagnosed by mapping actual chat/review communication, not the org chart.

## 2. The Four Fundamental Team 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, 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.

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 managerial convenience — most orgs need zero or one. A platform exists to remove load from streams: if adopting it is harder than self-hosting, it's a liability, not a platform. 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.

Apply: force ambiguous charters ("core services team") into one of the four types, e.g. a platform with internal customers and SLAs. Put deep specialist capability behind a simple interface (a recommendation-engine team exposing a scoring API). Time-box enabling engagements (test-automation specialists coach each stream for 8 weeks, then exit).

## 3. The Three Interaction Modes

Teams interact in exactly three modes: collaboration (close joint work for discovery), X-as-a-Service (one team consumes something another provides over a clear interface), and facilitating (one team helps another learn or improve). For every pair of interacting teams, choose one mode and declare it explicitly.

Key insights: collaboration is for discovery and is expensive — it blurs boundaries and raises both teams' cognitive load; time-box it, one collaboration per team at a time. X-as-a-Service trades discovery speed for predictability — right for established interfaces, wrong while the boundary is still unknown. Modes should evolve deliberately: collaborate to discover an interface, then shift to X-as-a-Service as it stabilizes. Persistent friction is organizational sensing data — awkward collaboration suggests a wrong boundary; a clunky service suggests the platform needs product work. A temporary, declared switch back to collaboration is standard when adopting a major new platform capability.

Apply: new platform capability → collaborate first, then shift to X-as-a-Service. Two teams stuck in endless meetings → declare the intended mode and cut standing syncs. Capability gap in a stream → a time-boxed facilitating engagement.

## 4. Team Cognitive Load and Team-Sized Software

Match responsibilities to a team's cognitive capacity. Three load types: intrinsic (skills and technology the work inherently demands), extraneous (delivery mechanics — tooling, environments, process), and germane (value-adding domain thinking). Minimize extraneous load, account for intrinsic load, protect capacity for germane load — size software to the team, never the reverse.

Key insights: measure domains, not headcount — one complicated domain per team, never two; a team can hold two or three simple domains; never split one complicated domain across teams. Bigger teams are not the fix for overload — fewer domains are; if the software exceeds team size, split the software. A team API makes the team consumable: code, docs, on-call, chat channels, and working agreements that let others interact without meetings. Long-lived teams beat project staffing — disbanding a gelled team discards months of trust, then pays the gelling cost again. Respect Dunbar-sized groupings: roughly 5-9 people per team, with natural limits near 15, 50, and 150 for groupings of teams. Extraneous load is the cheapest to remove — paved roads, templates, and platform services buy back germane capacity.

Apply: "core services team" charter forced into one of the four types with declared SLAs. Recommendation-engine complicated-subsystem exposes a simple scoring API. Enabling engagement on test automation ends after 8 weeks with capability transferred.

## Common Mistakes

Component teams cutting boundaries by technology layer instead of business stream. Undeclared or default-to-collaboration interaction modes that never evolve to X-as-a-Service. Teams holding two complicated domains at once — the cognitive-load equivalent of two full-time jobs. Reorgs treated as HR-only decisions with no architectural review. Platforms mandated rather than earning adoption through lower cognitive load than self-hosting.

## Quick Diagnostic

Does each team map to one of the four fundamental types? Is every team's interaction mode with its neighbors explicitly declared? Does any team hold more than one complicated domain? Would adopting the platform be easier than self-hosting the equivalent? Are reorgs reviewed as architecture decisions? Is total inter-team communication shrinking as boundaries mature?

## Source

Matthew Skelton and Manuel Pais, *Team Topologies: Organizing Business and Technology Teams for Fast Flow*.