In 2008, three researchers asked Microsoft for something unusual. Not the source code. The employee database.
Nachiappan Nagappan and Brendan Murphy of Microsoft Research, with Victor Basili of the University of Maryland, wanted to know whether you could predict which parts of Windows Vista would fail in the field without looking at what was inside them. Vista was 3,404 binaries and more than fifty million lines of code, built by several thousand engineers.
They built eight measures of the organization instead. How many engineers touched each component. How many had since left. How deep in the reporting tree the real ownership sat. How many separate organizations each contributed more than a tenth of the edits.
Then they let the model guess, and checked it against six months of actual post-release failures.
The HR data won
It identified failure-prone binaries correctly 86.2% of the time. The researchers then ran the same test using every metric the industry actually relies on.
| What the model looked at | Precision | Recall |
|---|---|---|
| Organizational structure | 86.2% | 84.0% |
| Code coverage | 83.8% | 54.4% |
| Code complexity | 79.3% | 66.0% |
| Code churn | 78.6% | 79.9% |
| Code dependencies | 74.4% | 69.9% |
| Pre-release bug counts | 73.8% | 62.9% |
Every code-based metric lost to the reporting structure. Coverage came close on precision, then collapsed on recall — it found what it found and missed nearly half.
The best available predictor of where a fifty-million-line system would break was not in the system. It was in the HR database.
None of this was news
Here is the part that should bother you. That finding surprised almost no one who read it.
Melvin Conway published the underlying claim in Datamation in April 1968 — after Harvard Business Review rejected it for failing to prove the thesis. Fred Brooks repeated it in The Mythical Man-Month in 1975 and gave it a name. Every enterprise architect alive can recite Conway’s Law on request. It appears on a slide in most architecture decks.
The argument is not complicated. Draw the system as a graph, components as nodes and interfaces as edges. Draw the organization the same way. Two components that exchange information required their teams to negotiate an interface, so there is an edge between those teams. Two components that do not exchange information required no negotiation, so there is none. Same graph. Not similar — the same one.
Conway’s own example is almost too tidy. A research firm had eight people and two compilers to build. Five went on COBOL, three on ALGOL. The COBOL compiler shipped in five phases. The ALGOL compiler shipped in three.
So the mechanism is documented, the effect is measurable, and the profession has known about it for nearly six decades.
And organizations keep producing the structures anyway. Which is the actual question. Not why does Conway’s Law hold — that part is settled. Why does knowing about it change nothing?
Because for each manager, every step is rational
Conway answered this in the second half of his paper, which is the half nobody quotes. It is not about architecture at all. It is about the incentives acting on the people who draw the boxes.
He names three. None is a technology decision, and each one is individually sensible for the person making it.
Delegation is schedule insurance.
A manager is exposed if he misses a date without having spent everything he was given. Assigning more people is not primarily a design judgment; it is protection against a specific accusation. The lead designer who would rather keep wrestling with the problem gets overruled by the risk calculus. And every delegation quietly deletes design options, because the communication paths required to pursue them stop existing.
Budget size is prestige.
Conway invokes Parkinson directly. While a manager’s standing rises with the size of his budget, he will grow his organization — and once the organization exists, it will be used. His claim is that the single largest common factor behind badly designed systems is the availability of a design organization in need of work. Not incompetence. Availability.
Failure has to be defensible.
This is the sharpest passage in the paper and almost nobody cites it. A manager must subcontract a hard problem. One bidder is small, new, and cheap, with an intuitively appealing approach. The other is established, conventional, and expensive. He knows that if the small firm fails he will be accused of mismanagement, and that if the established firm fails it will be taken as evidence the problem was genuinely hard.
The incentive does not point at the better outcome. It points at the survivable one. Fifty-eight years later, this is still why everybody in the room knows which name on the shortlist wins before the evaluation starts.
And the accounting makes it all add up
Underneath the three is an assumption that makes them look not merely rational but correct.
Conventional cost accounting treats two people working for a year and a hundred people working for a week as the same resource, because both reduce to the same number of dollars. Conway’s objection is that two people and a hundred people cannot work in the same structure — and by his own argument they will therefore not produce similar systems. The two efforts are not merely unequal in value. They may not be comparable at all.
His line is that assumptions adequate for peeling potatoes and building brick walls fail for designing systems.
If your business case is priced in person-years, it has already assumed away the thing that determines the outcome.
Which is why the AI reorg looks the way it does
Somewhere in your organization there is a new box on a chart. AI Platform. Center of Excellence. Agent Enablement. It was drawn in the last eighteen months by people trying to be deliberate.
It was also drawn under all three incentives at once. A capability that must be seen to be resourced. A budget whose size signals seriousness. A structure that will be defensible if the program underdelivers, which is the likeliest outcome and everyone knows it.
On the Vista evidence, that slide is a reasonably accurate forecast of the architecture you will have in three years, seams included. If the platform sits in its own box, you get a platform with an interface and everything past it becomes someone else’s problem. If governance reports somewhere other than where models get built, you get a review gate rather than a design constraint — and the system will route around it, because Conway’s edges follow who actually talks, not who appears above whom.
What actually changes it
Not a better diagram. The diagram is the output.
Conway saw this and said so in his conclusion, which reads oddly for 1968: ways must be found to reward design managers for keeping their organizations lean and flexible. He was not asking for better architects. He was asking for a different reward system, because he had just spent five pages explaining that the current one produces the structures nobody wants.
He also conceded the harder half. What needs communicating depends on the system concept in force at the time, and the first concept is almost never the best one. So the organization has to be able to change when the concept changes. Flexibility of structure, not correctness of structure — an awkward thing to ask of a company that has just announced a reorganization.
The useful part
The Vista study’s real contribution is not that organizational structure matters. Everyone says that, which is exactly why it changes nothing.
It is that structure is measurable, and the measurement beat every code metric they tested it against. Two of the eight measures are worth stealing outright. Depth of master ownership: how far down the tree before you find the manager whose people did most of the work — deeper is better. Organization intersection factor: how many separate orgs each contributed more than a tenth of the edits — lower is better, and three means the component has no owner regardless of what the chart says.
Both are computable from data you already hold. Neither requires reading code. And the authors noted the technique does not need Microsoft scale: roughly thirty engineers and three levels of reporting depth was enough.
So take the system that broke most often last year. Count the engineers who touched it, how many have left, how deep the real ownership sits, how many organizations had a hand in it.
You already know what you are going to find. The question is whether anyone is rewarded for acting on it.
Sources: Nachiappan Nagappan, Brendan Murphy and Victor R. Basili, "The Influence of Organizational Structure on Software Quality: An Empirical Case Study", ICSE 2008, Leipzig — figures from Table 3 and Section 5. Melvin E. Conway, "How Do Committees Invent?", Datamation, April 1968, full text published by the author at melconway.com.
Related Reading
Independent. No sponsorships. Unsubscribe anytime.