⌘ The Architecture Reference

Ms organization · Microservices · Intermediate

Conway's Law and Team Topologies

Systems mirror the communication structure of the organizations that build them — so align teams to business domains, use the four Team Topologies team types, and apply the Inverse Conway Maneuver incrementally.

Ms organization Intermediate ⏱ 4 min read Complete

🧭 Analogy

If three separate companies build a bridge — one for the deck, one for the cables, one for the towers — the seams between their work show up as the weakest joints in the finished bridge. Software is the same: the gaps in your org chart become the interfaces (and the coupling) in your system. Draw the teams the way you want the architecture to look.

Conway’s law

Mel Conway (1968): “organizations produce designs that copy their communication structures.” Newman shows MusicCorp’s three-tiered architecture (DBAs, backend, frontend) is Conway’s law in action — teams grouped by technical competency produce systems with high cohesion of technology and low cohesion of business functionality, so any single feature change ripples across all three layers and all three teams.

The evidence is strong: MacCormack’s product/organization “mirroring” study, the Windows Vista error-proneness study, Amazon’s two-pizza teams (which drove the creation of AWS), and Netflix. The fix for the three-tier problem is organizational: cross-functional teams aligned to domains.

graph TD
subgraph Tech["Teams by technical layer"]
  UI["UI team"] --> Layer1["smeared feature across 3 services"]
  BE["Backend team"] --> Layer1
  DBA["DBA team"] --> Layer1
end
subgraph Domain["Teams by business domain"]
  T1["Orders team"] --> S1["Orders service (end-to-end)"]
  T2["Payments team"] --> S2["Payments service (end-to-end)"]
end

The four Team Topologies team types

graph TD
SA["Stream-aligned teams<br/>(the majority)<br/>own a flow end-to-end"]
EN["Enabling teams<br/>help build new capabilities<br/>(reduce intrinsic load)"]
CS["Complicated-subsystem teams<br/>specialist subsystem (optional)"]
PL["Platform teams<br/>self-service tooling<br/>(reduce extrinsic load)"]
EN -.->|"facilitate"| SA
PL -.->|"X-as-a-service"| SA
CS -.->|"provide subsystem"| SA
  • Stream-aligned — the majority; own a valuable flow end-to-end, ideally including the UI via micro-frontends. The opposite of the layer-split.
  • Enabling — specialists who help stream-aligned teams build new capabilities, reducing their intrinsic cognitive load (the FT’s 3-month secondments to observability teams). Newman places architects here.
  • Complicated-subsystem — build/maintain a specialist subsystem (the FT’s Prometheus/Go example). Optional.
  • Platform — usually a group; reduce extrinsic load via self-service services built as a Thinnest Viable Platform (see ownership and platform teams).

The three interaction modes keep coupling low: Collaboration (intense, short, high-uncertainty work at a boundary), X-as-a-Service (the default for platform teams), and Facilitating (the enabling-team consultancy model).

The Inverse Conway Maneuver — incrementally

You can deliberately evolve the org to make the desired architecture easier — but it must be incremental, “pinching off” parts of system and org together, not a big reorg. “A reorganisation won’t fix a broken design,” and reorgs cause stress and attrition (“people aren’t resources”), so keep teams together and evolve over time.

💡 Team size and autonomy

Smaller is better — productivity worsens at nine or more. The challenge is building “large organizations out of smaller, autonomous teams,” minimizing coordination (Brooks’s Law) via a clear team API. But beware cargo-culting the “Spotify model” — “not even Spotify uses the Spotify model”; copy the questions, not the answers.

⚠️ Communication is the cost you're managing

Communication paths grow roughly quadratically with people, and Thoughtworks found cross-team-dependent tasks 10–12x slower in elapsed time (“backlog coupling”). Constant communication within a team is healthy; frequent high-bandwidth synchronous communication between teams couples them. Share key information asynchronously and searchably.

🔑 Key insight

If architecture and organization conflict, the organization wins — its communication structure reasserts itself. So design them together: align stream-aligned teams to business domains, support them with enabling, platform, and complicated-subsystem teams, and expect to iterate the boundaries.

See also

When to use it — and when not

✅ Reach for it when

  • You are aligning team structure with service architecture.
  • Your three-tier teams produce tightly coupled systems.
  • You want to evolve the org to enable a target architecture.

⛔ Think twice when

  • You have a single team and one deployable.
  • You need boundary-finding technique rather than org design.
ms-decompositionModeling Service Boundaries

Where to draw the lines — using information hiding, coupling/cohesion, the four (or five) types of coupling, and just-enough domain-driven design (aggregates and bounded contexts) to find stable boundaries.

ms-organizationOwnership and Platform Teams

Strong, active service ownership at scale, and the platform/enabling teams that provide a non-mandatory 'paved road' of self-service tooling — plus governance as guardrails, not gatekeeping.

ms-communicationChoreography vs Orchestration

Two ways to coordinate a multi-service business process: a central orchestrator that commands the flow, or choreographed services reacting to broadcast events — and when to choose each.

Check your understanding

Score: 0 / 4

1. What does Conway's law state?

Mel Conway (1968): a system's structure mirrors the communication structure of the organization that builds it.

2. What is a stream-aligned team?

In Team Topologies, stream-aligned teams are the majority; they own an end-to-end slice of business value, the opposite of the three-tier split.

3. What is the Inverse Conway Maneuver?

It's incremental ('pinching off' parts of system and org together); 'a reorganisation won't fix a broken design.'

4. When architecture and organization conflict, which wins?

Wells: build the org to support your architecture, because the org's communication structure will reassert itself.

Comments

Sign in with GitHub to join the discussion.