Takeaway

System designs reflect the communication structures of the organizations that build them; change the org if you want to change the architecture.

The problem (before → after)

  • Before: Teams ship architectures with unnecessary coupling and mismatched boundaries.
  • After: Align team boundaries and communication paths with desired system modules and interfaces.

Mental model first

If four teams build a compiler, you get a four-pass compiler: people naturally carve software along the lines they’re organized.

Just-in-time concepts

  • Inverse Conway maneuver: reorganize to match desired architecture.
  • Team topologies: stream-aligned, platform, enabling, complicated-subsystem.
  • Cognitive load as a design constraint.

First-pass solution

Map current communication paths; define target architecture; restructure teams and interfaces to reinforce desired module boundaries.

Iterative refinement

  1. Platform teams reduce coupling by providing stable interfaces.
  2. API-first contracts and documentation.
  3. Org evolution as the product evolves.

Principles, not prescriptions

  • You ship your org chart; design teams like you design code.
  • Minimize coordination; maximize autonomy within clear contracts.

Common pitfalls

  • Org changes without interface changes; misaligned incentives.
  • Over-fragmentation increases coordination overhead.

Connections and contrasts

  • See also: Team Topologies; microservices and APIs.

Quick checks

  1. Why do architectures mirror orgs? — Communication shapes boundaries.
  2. How to change architecture? — Change teams and interfaces.
  3. Why platform teams? — Reduce cognitive load and duplication.

Further reading

  • Conway (source above); Skelton & Pais