Conway’s Law gets quoted on slides so often that it feels like common knowledge. However, the original paper is more careful than the slogans, and the “inverse” idea built on top of it goes much further than Conway did.
What Conway Actually Wrote
Melvin Conway submitted “How Do Committees Invent?” to Harvard Business Review in 1967. According to Conway himself, the journal rejected it because he had not proved his thesis. Datamation then published it in April 1968.
The argument is simple. A system is a set of parts joined by interfaces. A design organization is also a set of groups joined by communication. Because two groups must talk to agree on an interface, the two graphs end up with the same shape. Conway even puts the word “proof” in quotation marks, and he calls the link a homomorphism.
His thesis, stated in the conclusion, is that organizations are “constrained to produce designs which are copies of the communication structures” of those organizations.
Quote check. The popular line with the word “inevitably” is not in the 1968 text. It comes from the author’s note Conway added 42 years later, on the same web page. The original wording is softer.
Two Small Examples From the Paper
Conway offers two short stories. In the first, a research firm had eight people to build a COBOL and an ALGOL compiler. Five worked on COBOL and three on ALGOL. As a result, the COBOL compiler ran in five phases, and the ALGOL one in three. In the second, two military services built a joint weapon and, after great effort, produced a copy of their organization chart.
A Warning About Management, Not a Recipe
Many readers miss the paper’s real target. Conway wanted to explain why large systems fall apart. Managers add too many people, communication fragments, and the system then reflects that fragmentation. His advice was modest: organize design work around the need to communicate, keep the organization lean, and stay flexible.
Notably, he also saw a loop. The team is organized around a preliminary system concept, and the team then shapes the design. Since the first concept is rarely the best, he argued that flexibility matters. Fred Brooks later gave it the name “Conway’s Law” in The Mythical Man-Month.
The Newer, More Prescriptive Idea
The Inverse Conway Maneuver is younger. Martin Fowler credits Jonny LeRoy and Matt Simons, who coined it in the December 2010 issue of Cutter IT Journal. Their original sentence was modest, though. It suggested breaking down silos that limit collaboration on creaky legacy platforms.
Over time, the meaning grew. Today it usually means changing the communication patterns of the designers to encourage a desired architecture. One critic argues that the definition has drifted from the original breaking-down-silos advice to “reshape the org to reach the target architecture”. Meanwhile, the book Team Topologies gave the idea a toolkit, with four team types: stream-aligned, enabling, complicated-subsystem and platform.
| Conway’s Law (1968) | Inverse Conway Maneuver | |
|---|---|---|
| Nature | An observation about design organizations | A technique you apply on purpose |
| Direction | Organization shapes the design, with feedback from the concept | Chosen architecture drives team design |
| Main advice | Organize around communication needs, stay flexible | Build autonomous teams aligned to target boundaries |
| Evidence at birth | A reasoned argument and two anecdotes | Practitioner experience |
| Main risk | Ignoring it | Freezing the wrong boundaries |
What the Evidence Says
Structure Predicts Quality
The best-known study is from Microsoft. Nagappan, Murphy and Basili studied 3,404 Windows Vista binaries, totaling more than 50 million lines of code. They compared organizational metrics, such as how many engineers touched a binary, against code metrics when predicting failure-prone components.
Organizational metrics scored 86.2% precision and 84.0% recall, ahead of code churn, complexity, dependencies, coverage and pre-release bugs on the combined picture. Even so, the authors note that the data comes from one very large system. The study also measured existing structure, so it supports “structure matters”, not “reorganizing gives you a new architecture”.
Mirroring Is Common, Not Universal
A broader review looked at 142 studies. Colfer and Baldwin (2016) found that mirroring was prevalent but not universal in firm and industry studies. By contrast, studies of open collaborative projects, mostly software, did not support it in the majority of descriptive cases.
The review also contains a warning for anyone planning a maneuver. In their summary of strategy studies, firms that built modular organizations for supposedly modular architectures, without enough knowledge of the technology, performed poorly. The authors call this premature modularization.
When the Maneuver Works, and When It Struggles
The maneuver works best when the target boundaries are well understood. For example, Fowler describes autonomous teams encouraging autonomous services in microservice setups, usually around business capabilities.
It struggles in tangled legacy systems. As ThinkingLabs argues, reorganizing around a complex, tightly coupled legacy system raises uncertainty sharply. In addition, new teams need time. Team Topologies, quoted by Mende, says a team may need from two weeks to three months or more to become cohesive.
Finally, remember Conway’s own warning. Because the first design is rarely the best, a reorganization that locks in today’s boundaries can hurt tomorrow.
A Practical Way to Use Both
Fowler lists three responses: ignore the law, accept it, or alter the team structure on purpose. In practice, start by accepting it. Map who actually talks to whom. Then change team boundaries where the mismatch with your architecture hurts most, and treat each new boundary as a hypothesis you will revisit.
What We Have Learned
Conway’s 1968 paper is a descriptive argument that design groups copy their own communication structure, and it warns managers to stay lean and flexible. It does not give a recipe for forcing an architecture. The Inverse Conway Maneuver, coined in 2010 and popularized through microservices and Team Topologies, turns the observation into a deliberate tool. Evidence supports the first idea well: a Windows Vista study found organizational metrics predicted failures better than code metrics, and a 142-study review found mirroring common in firms. Evidence for deliberate restructuring is thinner, and the same review warns about premature modularization. In short, use Conway’s Law to see your system clearly, and use the maneuver carefully, with boundaries you can still change.
