Most engineers know Conway's Law as a quote on a slide:
"Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure."
— Melvin Conway, "How Do Committees Invent?", Datamation, April 1968
It gets cited as folk wisdom — a clever observation, not something you would actually plan around. Then in 2008 a team at Microsoft Research and the University of Maryland decided to run the test on a real codebase that had just shipped. The codebase was Windows Vista. The result was uncomfortable enough that it should change how small teams think about architecture from day one.
What they actually measured
Nagappan, Murphy, and Basili built eight organizational metrics for every binary that shipped in Windows Vista. None of them looked at the code itself. They looked at the people:
- Number of engineers who touched the file
- Number of ex-engineers (people who edited and then left the org)
- Edit frequency at each org-chart level
- Depth of master ownership in the management tree
- Percent of the org that contributed edits
- Organizational code ownership level
- Overall organizational ownership concentration
- Organizational intersection factor (how many separate orgs touched the same binary)
Then they ran each metric against five well-known code-based predictive models — code churn, code complexity, code coverage, code dependencies, and pre-release defect history.
The target: predict which binaries would fail in production after release.
The number
Their organizational model produced 86.2% precision and 84.0% recall on post-release failure prediction. Every code-based model came in lower on at least one axis, and most came in lower on both.
Source: Nagappan, Murphy, Basili. The Influence of Organizational Structure on Software Quality: An Empirical Case Study. ICSE 2008.
The implication is sharper than "Conway's Law is real." The implication is that on a several-thousand-binary system, the best single signal for which parts will break is not how the code was written. It is who wrote it and how those people related to each other on the org chart. The organization is the predictor. The code is downstream.
Why this matters for small teams
The dominant reading of Conway's Law in industry has been defensive. Big company writes a microservices architecture that mirrors its team boundaries; everyone shrugs and says "Conway's Law strikes again." That framing treats the law as a constraint to manage around.
The Nagappan paper inverts the framing. If the org chart is the strongest single predictor of defect distribution, then the org chart is also the strongest single lever for changing defect distribution. Reorganizing the team is not a side activity. It is a code change with a 2008-validated impact on shipped quality.
For a solo founder or a small team this is unusually good news, for two reasons.
First: a solo developer is a single communication unit. There is no inter-team handoff, no module ownership war, no organizational intersection factor greater than one. Conway's Law predicts that the resulting architecture will be unified and coherent — not because the developer is gifted, but because the underlying communication graph has a single node. The solo systems that look "elegantly simple" compared to the 20-engineer enterprise rewrite of the same idea are not necessarily simpler because the founder is smarter. They are simpler because the org chart is one person.
Second: a small team gets to choose its architecture by choosing its boundaries first. Most architecture diagrams get drawn after the team is already formed. The Vista paper suggests that order is backwards. Decide what the system's modules need to be, then partition the team along those lines, then write the code. The "inverse Conway maneuver" is not new — Thoughtworks has been pushing the term for years — but the 2008 data is what gives it teeth. You are not just optimizing communication. You are choosing your defect distribution before you write the first line.
What this looks like in practice
A few patterns that follow from taking the Vista result seriously:
Module boundaries should track communication boundaries. If two engineers cannot have a five-minute conversation without scheduling, the modules they own should not share a public surface. The hand-off cost shows up in the codebase as defects later.
Hand-offs across organizational boundaries are the highest-defect surface. The Vista paper made "organizational intersection factor" — how many separate orgs touch the same binary — one of the strongest predictors. The fix is not better documentation. The fix is fewer intersections. Either move the binary so it lives in one org, or split it.
Adding a contributor is a code change. It changes who-edits-what, which the 2008 model says will measurably move the defect rate. Hiring the wrong person on the wrong module has architectural consequences that survive that person leaving (see "ex-engineers" as a separate predictor in the paper).
A solo system that grows to a two-person system is a riskier architecture transition than most people treat it as. You go from one communication node to a graph with one edge. Conway's Law predicts the architecture will fragment along that edge unless you specifically prevent it.
The 1968 paper deserves a re-read
Conway wrote "How Do Committees Invent?" after Harvard Business Review rejected it. Datamation published it in April 1968. The paper is short — four pages — and most of it is not about software. Conway uses examples from product design and committee meetings to make the point that any system, technical or organizational, ends up isomorphic to the communication graph of the people who built it.
The line that gets quoted everywhere is the one above. The line that should get quoted more is one paragraph later, where Conway notes that the design produced is not just isomorphic to the org chart — it is constrained by it. There are designs the organization cannot produce, no matter how good its engineers are, because the communication graph cannot support them.
That is the part the Vista paper validated forty years later. Not that org structure influences architecture — anyone shipping a microservice has noticed that — but that org structure is the strongest predictor of where the architecture will fail. If you accept that, the question stops being "what should this codebase look like?" and starts being "what does the team need to look like in order for the codebase to look like that?"
For a solo dev, the answer is already drawn. For a two-person team, the architecture decision and the hiring decision are the same decision, made on different days.
Sources
- Conway, M. How Do Committees Invent? Datamation, Vol 14 No 4, April 1968, pp 28-31. (melconway.com/research/committees.html)
- Nagappan, N., Murphy, B., Basili, V. The Influence of Organizational Structure on Software Quality: An Empirical Case Study. Proceedings of ICSE 2008.
Top comments (0)