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.

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.

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.

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.

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.

See: references/team-types.md

Core concept: Teams interact in exactly three modes: collaboration (two teams work closely together 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.

Why it works: Most organizational pain is an undefined interaction: a team expecting a service gets dragged into joint design; a team expecting coaching gets a ticket queue. Declared modes set mutual expectations, bound coordination cost, and turn interpersonal friction into a usable design signal.

See: references/interaction-modes.md

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

Why it works: When load exceeds capacity, teams thrash: context-switching, shallow ownership, defensive planning, rising lead times, on-call dread. Limiting domains per team keeps ownership deep enough for mastery, and long-lived teams amortize the months it takes a group to gel.

See: references/cognitive-load.md

Core concept: Split software along natural seams — fracture planes — so each piece can be fully owned by one team. Business domain (a DDD bounded context) is the default plane; the others are regulatory compliance, change cadence, team location/timezone, risk, performance isolation, technology, and user personas.

Why it works: Software larger than one team's cognitive load forces shared ownership, and arbitrary or layer-based splits recreate cross-team coupling. Splitting along seams that change together keeps most changes inside one team — and when service boundaries match team boundaries, Conway's law works for you instead of against you.

See: references/fracture-planes.md

Core concept: Run the platform as an internal product whose customers are the stream-aligned teams, starting from the Thinnest Viable Platform — the smallest thing that accelerates streams, which can be a wiki page curating vetted services. Then treat the whole topology as dynamic: use friction, wait times, and on-call signals to sense when team boundaries and interaction modes must change.

Why it works: Mandated platforms with captive users decay into bureaucracy because failure has no feedback channel; optional adoption forces the platform to stay compelling, and product discipline keeps it solving real needs. Orgs that treat topology as a one-time reorg drift back into Conway misalignment as products and markets shift.

See: references/case-studies.md

Matthew Skelton is the founder of Conflux, a consultancy for fast flow in software organizations, and co-author of Team Topologies. Manuel Pais is an independent IT organizational consultant and trainer specializing in team interactions and delivery practices. Both focus on team-first organization design that optimizes for fast, sustainable flow of change.