Conway's Law: The Empirical Evidence

In 1968 Melvin Conway published the paper How Do Committees Invent? in Datamation. Its central observation is usually quoted as organizations designing systems being constrained to produce designs that copy the communication structure of those organizations. Conway has said he submitted the paper to Harvard Business Review first and it was rejected. Fred Brooks later popularized the idea in The Mythical Man-Month, where it became known as Conway's law.

What the research says

For a statement that began as an essay, Conway's law has attracted a good amount of empirical testing.

Alan MacCormack, John Rusnak and Carliss Baldwin compared the architectures of products from different development settings and tested what they called the mirroring hypothesis, that the structure of a product mirrors the structure of the organization that built it. They found that loosely coupled organizations, such as distributed open source communities, tended to produce more modular products, while tightly coupled organizations tended to produce more tightly coupled products. Their work frames mirroring as common but not universal, since a firm can deliberately choose a different design and organize around it.

At Microsoft, Nachiappan Nagappan, Brendan Murphy and Victor Basili studied Windows Vista and found that organizational metrics, such as how many engineers touched a component and how the owning groups were arranged, predicted failure-proneness at least as well as traditional code metrics. Related work by James Herbsleb and others on global software development found that work requiring coordination across sites took longer, supporting the link between communication structure and product outcomes. A later review by Colfer and Baldwin examined the mirroring literature and concluded that the evidence supports the hypothesis in many settings while noting that it varies with context.

What practitioners see

Anyone who has watched a four-team organization produce a four-stage compiler, or a frontend, backend and database team produce a three-tier architecture even when the product needed something else, recognizes the pattern. Teams commonly report that service boundaries drift toward team boundaries, and that APIs between teams that do not talk often turn into rigid contracts.

Practitioners have turned the law into a tool. The inverse Conway maneuver, a term popularized in the ThoughtWorks Technology Radar, advocates shaping teams to encourage the architecture you want. Team Topologies, by Matthew Skelton and Manuel Pais, builds a vocabulary of team types and interaction modes around the same idea.

Many also find the maneuver harder than the slogan suggests: reorganizing is slow, people have careers and relationships, and architecture can lag the new structure for years.

Gaps

• Most studies show correlation within a specific setting; they do not demonstrate that reorganizing reliably produces the target architecture.
• Few studies examine modern cloud-native and platform team settings directly.
• Communication structure is hard to measure. Formal org charts differ from actual communication, which is what Conway described.
• Mirroring can be a result of rational choice rather than constraint, which makes causality difficult to isolate.

How to apply it

Treat your org chart as an architecture decision. Before drawing service boundaries, ask who will own each one and how often those owners must coordinate. If two services need a joint change in most releases, they probably belong with one team or one boundary.

Use code ownership data and co-change history to see the real communication structure, and compare it with the intended design. When designing a target architecture, plan the matching team changes, and sequence them so ownership and boundaries move together.

Minimize cognitive load per team by giving each a coherent area it can own end to end, and make interactions between teams explicit rather than accidental.

Key takeaways

• Conway's 1968 observation has moderate to strong empirical support, especially for modularity and quality outcomes.
• Mirroring is a tendency, not an iron law; deliberate design can break it.
• Organizational structure predicted software quality as well as code metrics in a well-known Microsoft study.
• The inverse Conway maneuver is plausible but weakly evidenced as a reliable lever.
• Design teams and boundaries together, and use ownership and co-change data to see actual communication.