Conway's Law
A reader's summary of Melvin Conway's 1968 observation that software architecture mirrors org charts — its rejected first home at Harvard Business Review, Fred Brooks's naming of it, and the deliberate org-design strategy engineering teams now build on top of it.
The term at a glance
Conway's Law holds that the structure of a system an organization builds will reproduce the structure of the communication channels inside that organization — three teams that don't talk to each other will, almost inevitably, produce a system with three loosely-integrated parts. It started as an offhand observation about software committees and is now a standard reference point in discussions of microservices, team design, and why some reorganizations quietly break the product.
Origins
Melvin Conway, a computer scientist, wrote up the idea in 1968 after observing how different teams approached system design. He submitted the paper to Harvard Business Review, which rejected it for lacking sufficient proof of the thesis. It was published instead in the April 1968 issue of the trade magazine Datamation, under the title “How Do Committees Invent?” — a modest venue for an idea that would go on to outlive most formally peer-reviewed management theory from the same decade.
History and context
The paper circulated in software-engineering circles for years before it had a catchy name. Fred Brooks, in his 1975 classic The Mythical Man-Month, cited Conway's observation and referred to it as “Conway's Law” — the label that stuck, even though Conway never coined it himself. Brooks's own book was already deep in the territory of how team structure warps software outcomes (see also the “adding manpower to a late project makes it later” observation known as Brooks's Law), which made Conway's idea a natural fit to cite alongside it.
Main claims
Rejected by Harvard Business Review
Conway submitted his 1968 paper to Harvard Business Review, which turned it down on the grounds that he hadn't proven his thesis; it ran instead in the trade magazine Datamation that April under the title "How Do Committees Invent?"
The one-sentence version
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure" — Conway's own wording, drawn from his observation of software teams rather than a formal experiment.
Brooks gave it a name, not Conway
Fred Brooks cited the paper as "Conway's Law" in his 1975 book The Mythical Man-Month, which is how most engineers encountered the idea — Conway himself never used that name for it.
The compiler anecdote
Conway illustrated the point with a widely repeated (and hard to source precisely) claim: a team of eight assigned to build a COBOL and an ALGOL compiler split into two four-person groups and delivered exactly two compilers, whatever the actual task required.
The Inverse Conway Maneuver
If org structure determines architecture, teams can work the causation backward: restructure the org chart first — small, autonomous, cross-functional teams — to make the desired decoupled architecture (e.g. microservices) the path of least resistance, a move popularized by ThoughtWorks and formalized in Matthew Skelton and Manuel Pais's 2019 book Team Topologies.
Critique
- It was never an experiment. Conway's original paper offered reasoning and illustrative anecdotes, not a controlled study — the Harvard Business Review rejection was specifically about the lack of proof, and later academic attempts to test the claim empirically (notably a 2008 Harvard Business School study of open-source versus proprietary codebases) found the correlation real but weaker and more conditional than the pithy one-liner suggests.
- Direction of causation is debatable. The law is usually read as org structure causing architecture, but the relationship can run the other way — a legacy system's existing structure can just as easily calcify the teams built around maintaining it, which is part of the argument for treating reorganization and re-architecture as a single joint decision rather than two.
- The Inverse Conway Maneuver can be cargo-culted. Copying Amazon's “two-pizza teams” or Spotify's squad model doesn't automatically produce Amazon's or Spotify's architecture — both companies iterated their org-to-architecture mapping over years against their own specific product, and the borrowed org chart without the borrowed context is a common failure mode critics of the “Spotify model” have pointed out since.
- It can justify silos as much as challenge them. Because the law is often invoked to argue for splitting teams into smaller autonomous units, it can be used to rationalize fragmentation and duplicated effort just as easily as it's used to diagnose accidental coupling — the label doesn't by itself say which direction a given org should move.
Impact
Conway's Law is now cited constantly in discussions of microservices adoption, platform teams, and API-first mandates — including the (unverified but widely repeated) story of Jeff Bezos's internal Amazon memo requiring all teams to expose their data and functionality through service interfaces, treated in retrospect as a textbook Inverse Conway Maneuver. Team Topologies (2019) turned the maneuver into a full methodology of stream-aligned, platform, enabling, and complicated-subsystem teams, and it is now a standard reference in engineering-organization design well beyond the original committee-and-compiler framing.
Notable engagements
- Melvin Conway, “How Do Committees Invent?”, Datamation (April 1968) — the original paper, published after Harvard Business Review declined it.
- Fred Brooks, The Mythical Man-Month (1975) — coined the name “Conway's Law” and carried it into mainstream software-engineering vocabulary.
- Harvard Business School study of open-source vs. proprietary codebases (2008) — a later empirical attempt to test the correlation between team structure and code modularity.
- Matthew Skelton and Manuel Pais, Team Topologies (2019) — formalized the Inverse Conway Maneuver into a team-design methodology now widely used in platform-engineering practice.