Conway's Law
Organizations design systems that mirror their own communication structures.
Also known as: Conway Law, Inverse Conway Maneuver, Reverse Conway Maneuver
Category: Software Development
Tags: architecture, software-engineering, organizational-design, teams, systems, laws
Explanation
Conway's Law, articulated by computer programmer Melvin Conway in 1967, states that 'organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.' This observation has profound implications for software architecture. If four teams work on a compiler, you'll get a four-pass compiler. If teams don't communicate, their systems won't integrate smoothly. The law works bidirectionally: organizational structure shapes system architecture, but you can also use desired architecture to inform organizational design (the 'Inverse Conway Maneuver' or 'Reverse Conway Maneuver'). Key implications: (1) Team boundaries become system boundaries, (2) Inter-team communication overhead creates system integration complexity, (3) Isolated teams produce isolated components, (4) Cross-functional teams produce more integrated solutions. In practice: microservices work best when teams are organized around services (one team per service), monoliths often reflect organizations with high cross-team communication, and modular monoliths work well with teams that have clear domain ownership but shared deployment. The law explains why reorganizations often precede architecture changes and why 'architecture astronauts' who design systems ignoring organizational reality often fail. Modern approaches like Team Topologies explicitly use Conway's Law, designing team structures to produce desired architectural outcomes. Understanding this law is essential for technical leaders making architectural decisions—the best architecture is one that your organization can actually build and maintain.
Related Concepts
← Back to all concepts