Manu's Vault

Conway's Law

4 min readStatus:Seedling

Core Idea

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” This fundamental principle reveals that system architecture mirrors organizational structure, not by accident but by necessity.

Conway’s Law Explained

Conway’s Law, formulated by Melvin Conway in 1967:

  • States that the structure of any system designed by an organization will inevitably reflect the communication structure of that organization
  • This is not merely an observation but a constraint
  • Teams building software cannot help but create architectures that mirror how they communicate and collaborate

The mechanism is straightforward:

  • When building a system, teams must coordinate and share information
  • The boundaries between components naturally form where communication becomes difficult or expensive
  • If you organize teams by technical layers—a backend team, a frontend team, and a database team—you will almost certainly produce a layered architecture
  • Each team builds what they understand and can coordinate internally, with well-defined interfaces at the boundaries where they must coordinate externally

Conversely, if you organize teams by business domain:

  • An Order domain team, a Payment domain team, and a Delivery domain team
  • You will tend to produce a modular or domain-driven architecture
  • Each team owns a complete vertical slice of functionality, from database to UI, within their domain
  • The component boundaries reflect domain boundaries, not technical ones

This insight has profound implications for component identification and architecture design:

  • You cannot simply choose an architecture style in isolation
  • If your organizational structure doesn’t match your desired architecture, one of two things will happen:
    • Either the architecture will drift toward matching the organization
    • Or the organization will experience constant friction and communication overhead trying to maintain an incompatible architecture

Successful architects recognize Conway’s Law as both a constraint and a tool:

  • As a constraint: it means you must consider organizational structure when designing systems
  • As a tool: it suggests that reorganizing teams—what some call the Inverse Conway Maneuver—can help achieve a desired architectural outcome. Rather than fight the law, modern practitioners advocate evolving team structure and architecture together to promote the desired system design (Martin Fowler; Chris Ford: “Conway understood that software coupling is enabled and encouraged by human communication.“)
  • If you want a microservices architecture with independent, loosely coupled services, you need independent, loosely coupled teams. Conway’s Law is widely regarded as the single most influential factor on software architecture among practitioners

Why This Matters

Conway’s Law explains why many architectural transformations fail despite technical soundness:

  • Organizations attempt to “move to microservices” while maintaining centralized platform teams, shared database administrators, and layered team structures
  • The architecture cannot stabilize because it fights against the organization’s communication structure

Understanding this law allows architects to:

  • Align organizational design with architectural goals
  • Recognize when organizational constraints make certain architectures impractical
  • Shift the conversation from “what’s the best architecture?” to “what architecture can our organization actually sustain?”

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks