The Mirror of the Organization – Conway's Law and the Evidence on Mirroring

The Hook

A company sets up three teams: frontend, backend, database. Eighteen months later the system – surprise – has three layers, and every new feature needs three tickets, three sprint plannings, and a coordination meeting. Another company sets up five teams along business capabilities: catalog, cart, payment, shipping, account. Its system breaks down into five services with narrow interfaces.

Coincidence? In 1968, Melvin Conway argued: no. His thesis is known as "Conway's Law" and is quoted often in architecture discussions. I am of the opinion that the original paper, by contrast, is rarely read. This article therefore asks two things: What did Conway actually write? And what does the empirical research of the following decades say – does the "law" hold, and where are its exceptions?

The Core Concept: What Conway Actually Wrote

The paper is titled How Do Committees Invent? and appeared in April 1968 in the magazine Datamation. Conway himself states its conclusion as the "basic thesis": organizations that design systems (in a broad sense of the word) are constrained to produce designs that are copies of the communication structures of these organizations.

Three details of this formulation are often blurred in popular retellings:

1. Communication structure, not the org chart. Conway speaks of communication structures. The formal org chart is only an approximation; who talks to whom every day counts for more than reporting lines.
2. "Constrained" – a constraint, not a natural law in the physical sense. Conway argues that two subsystems can only work together cleanly across an interface if their designers communicate with each other. Where there is no communication, no finely tuned interface emerges.
3. A mathematical core. Conway models both the system and the organization as graphs and describes the relationship as a structure-preserving mapping – explicitly called a homomorphism in the text: from the graph of the system to the graph of the design organization.

His best-known example: a contract research organization had eight people who were to build a COBOL and an ALGOL compiler. Five were assigned to the COBOL job, three to the ALGOL job. The resulting COBOL compiler ran in five phases, the ALGOL compiler in three.

Less well known, but more important in practice, is Conway's conclusion: because the design that comes first is almost never the best possible one, the prevailing system concept may need to change – and therefore flexibility of organization is important to effective design. So Conway describes not only a phenomenon but a danger: an organization fixed early cements an early, probably suboptimal design.

From Anecdote to Hypothesis: Mirroring

Conway's paper is an argument with examples, not an empirical study. Organization and innovation research later took up the idea under the name mirroring hypothesis: organizational ties (communication, co-location, shared employment) should correspond to the technical dependencies in the product. This makes the thesis testable – one can measure and compare dependencies in code and structures in organizations.

Example 1: Five Product Pairs and a Factor of Eight

Alan MacCormack, Carliss Baldwin, and John Rusnak (Research Policy, 2012) tested the hypothesis with matched product pairs: in each case one product from a tightly coupled organization (a small, dedicated team, usually within a company) and a functionally comparable product from a loosely coupled organization (a distributed open-source community). What mattered was how the development team was organized, not the license – some of the tightly coupled products later became open source themselves. The sample comprised five pairs from financial software, word processing, spreadsheets, databases, and operating system kernels; since Linux was compared with both Solaris and XNU, there are six comparisons.

Modularity was measured via propagation cost: the share of system elements that can be affected, on average, when a randomly chosen element is changed – computed from the dependencies between source files.

The result, according to the abstract: in all pairs examined, the product of the loosely coupled organization was significantly more modular. The differences were substantial – up to a factor of eight in the potential for a change in one component to propagate to others. (The table in the working-paper version shows the largest propagation-cost ratio as about 6 : 1 – 47.14% versus 7.74% for the financial software pair; figures in the journal version may differ.)

It is important to note what the study does not show: it observes a correlation in a small sample. Whether the organization causes the architecture, or whether modular products tend to attract distributed communities, cannot be cleanly separated with five pairs.

Example 2: 142 Studies – Common, but Not Universal

Lyra Colfer and Carliss Baldwin (Industrial and Corporate Change, 2016) systematically reviewed the literature: 142 empirical studies, divided into industry studies, firm studies, and studies of open collaborative projects.

Their findings:

The authors' explanation for the exception: digital technologies make possible new modes of coordination that allow groups to deviate from classical mirroring as seen within firms. That is an interpretation, not causal proof. I am of the opinion that version control, public issue trackers, and code readable by everyone are plausible candidates for replacing part of what direct communication would otherwise have to accomplish.

Note the difference from Example 1: there, open source confirms the hypothesis – loosely coupled communities build more modular products. The exception in Colfer and Baldwin concerns something else: in open projects, technical dependencies more often do not line up with organizational ties.

Two further concepts from the paper are useful for architects:

• The mirroring trap: firms focused on their current technical architecture can fall victim to architectural innovations that arise outside their boundaries.
• Partial mirroring: in technologically dynamic industries, drawing knowledge boundaries more broadly than operational boundaries – knowing more than you build yourself – is likely to be the superior strategy.

Example 3: Organizational Structure as a Quality Predictor at Windows Vista

If communication and architecture are linked, the organization should also reveal something about defects. Nachiappan Nagappan, Brendan Murphy, and Victor Basili (Microsoft Research, technical report MSR-TR-2008-11) examined this for Windows Vista. They defined eight organizational metrics – for example, how many engineers worked on a binary, how many of them had left the company, and how widely ownership was spread across the organizational hierarchy.

According to the abstract, these metrics were statistically significant predictors of the failure-proneness of binaries. Precision and recall in identifying failure-prone binaries were significantly higher than with traditional metrics such as code churn, complexity, coverage, dependencies, or pre-release bugs. The report states an average precision of 87% and an average recall of 84% across 50 random splits into training and test data.

The limitation: this is one product in one company. The study itself does not show whether the result transfers to other organizations.

Example 4: The Price of Distance

James Herbsleb and Audris Mockus (IEEE Transactions on Software Engineering, 2003) studied how long changes take in a large telecommunications project. Their central finding: work items distributed across sites took about two and a half times as long as comparable work items whose work was done at one site. As a mechanism, the data suggest that distributed work involves more people, and the number of people involved is strongly related to completion time. When the regression accounts for the number of people involved (as well as size, spread across modules, and severity), the site effect is no longer significant – the delay therefore runs through the number of people involved.

This is the flip side of Conway's thesis: where architecture forces interfaces that cut across communication paths, you pay in coordination time.

Framework: The "Inverse Conway Maneuver"

If the organization shapes the architecture, the lever can be reversed. In 2014, the ThoughtWorks Technology Radar listed the technique "Inverse Conway Maneuver" in the "Trial" ring: evolve team and organizational structure to promote the desired architecture.

A practical translation into four questions:

The empirical evidence, however, counsels modesty. Colfer and Baldwin find mirroring to be common but not universal, and explain the exceptions in open projects with new, digitally enabled modes of coordination – so the maneuver is not a mechanism with guaranteed effect. I am of the opinion that it is best understood as a hypothesis to be checked against metrics (coordination effort, lead time, coupling in the code).

The Central Takeaway

• Conway's thesis is an observation about communication, not about org charts – and it is empirically confirmed often, but not without exception.
• Architecture decisions are organizational decisions. Anyone planning a cut in the system should check whether the teams building both sides communicate accordingly – or, conversely, do not need to.
• Distribution costs time – through the number of people involved. In the study by Herbsleb and Mockus, cross-site work items took about two and a half times as long because more people were involved. I am of the opinion that interfaces should therefore lie where little coordination is needed anyway.
• Tools can cloud the mirror. In open projects, coupling in the code more often deviates from organizational ties – presumably because version control and public communication replace part of the direct coordination. At the same time, loosely coupled communities tend to build more modular systems.
• A rigid organization cements early designs. Organizational flexibility is an architectural quality.

Cross-References in the Vault

• The Promise Nobody Can Keep: Two-Phase Commit, Sagas and the End of the Distributed Transaction – when service boundaries follow team boundaries, transactions across team boundaries become a problem.
• The Logbook of Truth: Understanding Event Sourcing and CQRS – events as a narrow interface between teams.
• How Machines Come to Agree: Distributed Consensus from FLP to Paxos to Raft – coordination between machines as the technical counterpart to coordination between people.
• The Long Tail of Latency: Tail Latency and Why Averages Lie in the Cloud – fan-out across many teams has a long tail, too.

Food for Thought

Draw your team's communication paths over the last four weeks – not the org chart, but who actually talked to whom. Place this picture next to your system's dependency diagram: where do the two match, and where does your architecture force conversations that your organization isn't having at all?

Fact Check

Automated AI check against primary sources; no human expert review.

58 claims were checked (24 hard facts, 8 quotes or attributed phrasings, 11 source attributions, 15 synthesis claims). 8 passages were corrected or softened. The most important corrections:

• The shares of 70% / 22% / 8% in Colfer and Baldwin refer only to the descriptive industry and firm studies, not to all descriptive studies.
• The mechanism in Herbsleb and Mockus was made more precise: the site effect disappears once the number of people involved is taken into account.
• An internal contradiction was resolved: in MacCormack et al., open source confirms the mirroring hypothesis, whereas Colfer and Baldwin find more deviations in open projects – two different statements that the draft had conflated.

Sources and Further Reading

1. Conway, M. E. (1968): How Do Committees Invent? Datamation, April 1968. https://www.melconway.com/Home/Committees_Paper.html
2. MacCormack, A., Baldwin, C., Rusnak, J. (2012): Exploring the duality between product and organizational architectures: A test of the "mirroring" hypothesis. Research Policy 41 (8), 1309–1324. https://doi.org/10.1016/j.respol.2012.04.011 – Working paper: https://www.hbs.edu/ris/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf
3. Colfer, L. J., Baldwin, C. Y. (2016): The mirroring hypothesis: theory, evidence, and exceptions. Industrial and Corporate Change 25 (5), 709–738. https://doi.org/10.1093/icc/dtw027
4. Nagappan, N., Murphy, B., Basili, V. (2008): The Influence of Organizational Structure on Software Quality: An Empirical Case Study. Microsoft Research, MSR-TR-2008-11. https://www.microsoft.com/en-us/research/publication/the-influence-of-organizational-structure-on-software-quality-an-empirical-case-study/
5. Herbsleb, J. D., Mockus, A. (2003): An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering 29 (6), 481–494. Preprint: https://mockus.org/papers/delay.pdf
6. ThoughtWorks Technology Radar: Inverse Conway Maneuver (Trial, July 2014). https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver

← All articles