A contract research firm had eight programmers and two jobs. It needed a compiler for COBOL and a compiler for ALGOL, two programming languages of the day.
The managers sized up the work and split the people: five on COBOL, three on ALGOL.
The COBOL compiler came out running in five phases. The ALGOL compiler ran in three.
Nobody had designed it that way on purpose. The programmer Melvin Conway put the example in a 1967 paper with a second one beside it. Two military services had been ordered to develop a common weapon system that met both their needs. “After great effort,” Conway wrote, “they produced a copy of their organization chart.”
The thesis in the third-last paragraph
Conway sent the paper, “How Do Committees Invent?”, to the Harvard Business Review. The editors turned it down. By his own account, the reason was that he “had not proved” his thesis.
He sent it to Datamation, the leading computer magazine of the time, which published it in April 1968. Decades later he joked that its most remarkable feature was getting into print “with its thesis statement in the third-last paragraph.” Here it is: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
The reason is practical. Building anything big means deciding where one part ends and the next begins. People who sit together and talk every day can work across that line. People in different groups, who talk through managers and meetings, need the line to be clean so they can work apart. So the seams in the product fall where people stop talking every day.
A few years later Fred Brooks quoted the idea in The Mythical Man-Month and called it “Conway’s Law.” The name stuck. Systematic evidence took longer.
Forty years later, at Harvard
In the 2000s, a team at Harvard Business School, Alan MacCormack, John Rusnak and Carliss Baldwin, set out to test what they called the mirroring hypothesis. They matched pairs of software products that did similar jobs. In each pair, one came from a tightly knit team inside a company and the other from a loose, spread-out group, such as an open-source project.
Then they measured how far a change to one file could ripple through the rest of the system. In Sun’s Solaris operating system, the figure was over 22%: on average, a change to one file could touch more than 2,400 others. In Linux, built by a loosely connected community of contributors, it was around 7%.
“In all of the pairs we examine,” the researchers wrote, “the product developed by the loosely-coupled organization is significantly more modular.” The gap reached up to a factor of eight.
It was a comparison of matched pairs, which shows a strong pattern rather than a law that holds everywhere. The pattern was the one Conway had described. Teams that couldn’t lean across the desk had built software in pieces that didn’t lean on each other either.
Running the law backwards
If the product copies the organization, you can try to shape the product by shaping the organization first. By one former engineer’s account, that is roughly what Jeff Bezos did at Amazon around 2002, ordering every team to talk to other teams only through published service interfaces, on pain of being fired. Amazon’s software was rebuilt as separate services, run by small teams that each owned one piece.
A team made of agents
Builders of AI systems now draw org charts too. MetaGPT, a research framework for software-writing agents, defines five roles “in our software company: Product Manager, Architect, Project Manager, Engineer, and QA Engineer,” and passes work between them using what its authors call “an assembly line paradigm.” The team structure is copied from people, deliberately.
Carrying Conway’s idea over to agents is a reasonable guess, not a tested result. Still, it gives a question worth asking of any setup like this. Every handoff between roles is a place where a seam can form. Are those the seams you want in the product?
The customer’s route
Now imagine a bank that never ran the law backwards. The current account sits in one app, the credit card in another with its own login, and the mortgage team only takes calls. A customer moving money between the three has to cross the same lines the managers do. Each team did its job well. The customer is walking through the org chart.