Conway’s Law: Your System Is Shaped by Who Actually Talks to Whom

Conway’s Law is a 1968 finding from the computer scientist Melvin Conway. It explains why a company’s software ends up shaped by who actually has to work together, not by the chart that says who is in charge. That is why some reorganisations change nothing: the code still fits whoever actually ships it. What works instead is making who approves, releases and gets paged match how work really flows.

In a 2025 podcast, McKinsey said its research suggests even high-performing companies miss about 30% of their strategy’s potential, and that the right operating model can close that gap. Conway’s Law is one plain, mechanical reason the gap opens: the structure nobody redesigned on purpose is still doing the deciding.

McKinsey Talks Talent podcast, 30 July 2025, “How the right operating model can close your performance gap.” mckinsey.com

Where the law comes from

Melvin Conway sent a paper called “How Do Committees Invent?” to the Harvard Business Review in 1967. The magazine rejected it, saying he hadn’t proved his point, so he sent it to Datamation instead, which published it in April 1968. The software engineer Fred Brooks read it, named the finding Conway’s Law in his book The Mythical Man-Month, and the name stuck.

Melvin Conway, on the paper’s rejection and its naming. melconway.com · Melvin E. Conway, “How Do Committees Invent?” Datamation, April 1968. melconway.com

His own paper states the finding directly: “The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”

In Conway’s own example, a research group split eight people into a five-person team and a three-person team to build two compilers, one for COBOL and one for ALGOL. A compiler is the program that turns code a person writes into instructions a computer can run, and COBOL and ALGOL were two programming languages of the day. Each compiler ended up with as many phases, or stages, as its team had people. As the paper puts it, an organisation that isn’t completely flexible in how it communicates “will stamp out an image of itself in every design it produces.”

Talking is expensive, and that expense draws the lines

When two teams build two parts of a system, they have to agree where one part ends and the other begins. The harder those teams find it to talk, the more each agreement costs, so the parts end up meeting only where the teams already talk. Split the organisation, and the system splits the same way, whether or not anyone drew it that way on a whiteboard.

The org chart isn’t the real map

The org chart on the intranet shows reporting lines, not communication, and Conway’s Law is about communication. The useful map is different: who actually has to sign off before a change ships, and who actually talks to whom to get that sign-off. In a healthy structure, that real map and the org chart mostly agree. In a struggling one, they diverge. A team reports up through one manager, but every real approval for its changes runs through someone in a different part of the company, because that is where the authority to say yes actually sits.

The divergence itself is the diagnosis: draw the real map, then compare it with the org chart.

The fix has to be something a tool checks

Naming Conway’s Law only diagnoses the problem. Three things fix it, and a tool enforces each one:

• A CODEOWNERS file with its branch rule switched on. This is a file, a GitHub or GitLab feature, that names which team owns each part of the code. The branch rule is the setting that turns ownership into a requirement: it blocks any change to that part until the owning team approves it.
• Deploy permissions that match the file. A service is a part of the system that runs on its own, and whoever can put a new version of one live should be the team the file names as its owner.
• An on-call rota that matches too. Whoever gets paged when a service breaks is its real owner, whatever the file says.

None of this is expensive to check, because each answer is a plain yes or no in a settings page or a file. Does a change need the owning team’s approval? Can anyone else put that service live? Does the on-call rota name that team, and does that team still exist?

The system already knows your real org chart.

None of this argues for reorganising around today’s system, or rebuilding the system around today’s chart. Conway’s Law applies whether anyone checks it or not. The only real choice is whether the shape it produces is the one you would have designed on purpose.

Updated 26 Sep 2026: we removed a figure about how many transformation phases are rated successful, which none of the McKinsey pages the earlier version cited contain. We also replaced a derived figure, “around 70%” of potential captured, with McKinsey’s own terms: a 30% gap.