Skip to content
Knowledge beta

Conway's Law

Organizational Design Team Topologies

Your software architecture will end up looking like your org chart whether you like it or not. The big question: have you done this on purpose or by accident?

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin Conway, 1968

The observation is deceptively simple: your architecture mirrors your org chart. Not because anyone planned it that way, but because it gradually evolved that way without too much thought. Teams that don’t talk to each other produce systems that don’t integrate well. Teams that share too many dependencies produce Big Balls of Mud.

Why It Matters

Conway’s Law isn’t a suggestion. It’s a constraint. You can either fight it or use it.

Fighting it looks like: redesigning an architecture without changing the team structure. The org chart reasserts itself. Interfaces between teams become interfaces between components, regardless of what the whiteboard says.

Using it looks like: deliberately shaping team boundaries to produce the architecture you want. This is the core insight behind Team Topologies — if you want independent, loosely coupled services, you need independent, loosely coupled teams.

Practical Implications

  • Monolith-to-microservices migrations that don’t restructure teams tend to produce distributed monoliths (the worst of both worlds).
  • Cross-team dependencies are architecture smells. If two teams must coordinate on every release, their components are coupled whether their architecture diagrams show it or not.
  • Cognitive load compounds the effect: when team boundaries are misaligned with the architecture, every interaction adds extraneous overhead that has nothing to do with the domain.

The Inverse Conway Maneuver from Team Topologies (reorganizing teams around a desired architecture, level of abstraction, and/or bounded contexts) is now a standard practice in organizations adopting Team Topologies. Visualizing the resulting architecture with the C4 model makes the alignment (or misalignment) between teams and components legible at a glance.

Resources