rgoussu.dev
rgoussu@goussu: ~/library/engineering-practice
❯ ~/library/engineering-practice cat team-topologies-and-conways-law.md

Team topologies & Conway's law

# Organization design as architecture — Conway's law, the four team types and three interaction modes, and cognitive load as the sizing rule.

Conceptsaved 2026-08-08 #team-topologies#conways-law#organization#architecture#process

Overview

Conway's law — systems mirror the communication structures of the organizations that build them — is the most consequential observation in software architecture, because it runs in both directions: you can fight your org chart with architecture and lose, or design the org to produce the architecture you want (the "inverse Conway maneuver"). Team Topologies (Skelton & Pais) turned that into a usable vocabulary: four team types, three interaction modes, and cognitive load as the limit that sizes everything.

Key points

  • Conway's law is a constraint, not a curiosity: two teams that must coordinate through meetings will ship two components integrated the way those meetings go — badly. Service boundaries that cut across team boundaries generate permanent friction; this is why microservices ownership ("one team, one service, you build it you run it") and DDD bounded contexts keep converging on team lines — a bounded context that spans teams is a context map with a fault in it.
  • Four team types, and only four: stream-aligned (the default — owns a slice of user-facing value end to end), platform (makes stream teams faster by productizing the underlying capabilities — see platform engineering), enabling (temporarily grows capability in other teams, then leaves), complicated subsystem (guards a genuinely specialist component). Most org confusion is a team with no clear type — or a "platform" team that's actually a bottleneck with a backlog.
  • Three interaction modes: collaboration (high-bandwidth, temporary — for discovery), X-as-a-Service (low-bandwidth, stable — the target state for platform↔stream), facilitating (enabling's mode). The failure smell is permanent collaboration everywhere: it feels agile and scales as O(n²) meetings.
  • Cognitive load is the sizing rule: a team owns what it can hold in its head — when a team's domain outgrows it, quality drops before headcount math notices. Split by fracture planes (business domain first; also regulatory, performance, technology maturity) — not by architectural layer, which is how you get a "frontend team" and a "backend team" shipping every feature through two backlogs.
  • Team API: each team publishes how to interact with it — what it owns, how to request work, its communication channels, its docs — treating the team boundary with the same explicitness as a service contract (API design for humans).
  • The platform is judged like a product: internal platforms compete with "teams doing it themselves" — adoption is voluntary or it's just centralization; thinnest viable platform first.
  • To explore: inverse Conway case studies, Dunbar-number team sizing, flow metrics per stream team, how remote/async shifts the communication structures Conway's law mirrors.

Practice

  • Map an org you know (source) — draw a past employer's teams using the four types and three interaction modes, color anything unclassifiable; teaches the vocabulary by exposing the teams with no clear type and the "collaboration everywhere" smell.
  • Write a Team API (source) — fill the official template for your current (or last) team: what it owns, how to request work, its channels and docs; teaches the team boundary as an explicit contract — the gaps you can't fill are the finding.
  • Independent Service Heuristics pass (source) — score three candidate service/team boundaries from a system you know against the ISH checklist; teaches fracture-plane selection with a concrete instrument instead of taste.
  • Wardley map the same org (source) — map a known product's value chain by evolution stage, then overlay the team boundaries from the first drill; teaches where platform teams belong (commodity end) and which "custom" components deserve stream teams.

Related