Conway's law: what does it say and how do you use it in reverse?

Conway's law is the observation that any organization that designs a system produces a design whose structure copies the organization's own communication structure. In Melvin Conway's original wording: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." In practice, if two departments in a company barely talk to each other, the two software modules those departments write will not talk to each other either, regardless of how good the chosen technology is. It is not a physical law or a theorem: it is an observed pattern seen repeatedly in enterprise software, and should be treated as an operational warning, not an absolute constraint. It holds for an ERP, a CRM, a data platform: any system designed by more than one person or team inherits, without anyone deciding it on purpose, the map of who talks to whom.

See also: Team Topologies · An organizational design model for software: four team types and three interaction modes, sized by cognitive load.

The source, the date, and a name its author never used

Melvin Conway published "How Do Committees Invent?" in Datamation in April 1968, after the Harvard Business Review had rejected it on the grounds that, in their view, he had not proven his thesis. The full text is still readable on the author's own site, melconway.com. One detail almost every secondary source gets wrong: the name "Conway's law" was not coined by Conway, who never uses it in the original article, but by Fred Brooks, who names it that way in "The Mythical Man-Month" while citing this exact paper. The observation stayed largely anecdotal for decades, until MacCormack, Baldwin and Rusnak, in "Exploring the Duality Between Product and Organizational Architectures" (Research Policy, 2012), tested it on real software products by comparing open source teams, typically loosely coupled, against more rigidly structured commercial teams. The result, as reported by the authors themselves, is strong support for the "mirroring hypothesis": in direct comparisons between equivalent products, the one built by the more loosely coupled organization was consistently more modular than the one built by the more tightly coupled one.

A concrete example

A manufacturing company with sales, production and logistics run by three managers who only coordinate in a monthly meeting decides to replace its old management software with a new ERP. The vendor delivers a modular system, but the three modules, sales, production, logistics, stay nearly as disconnected as before: orders get entered twice, stock levels do not update in real time across departments. This is not the product's fault: the implementation team simply mirrored, inside the software, the same lack of communication that already existed in the organization, the same pattern described in the entry on data silos. Changing technology without changing who decides what and who answers to whom produces, almost every time, the same fracture with a different interface.

Why it matters for decision makers

The operational consequence has a name: the inverse Conway maneuver, coined by Jonny LeRoy and Matt Simons in 2010 and made operational by Skelton and Pais in "Team Topologies". If the organization determines the architecture, then to get the architecture you want you change who works with whom first: one owner and one group across the order-to-shipment flow, instead of three departments meeting monthly, is what makes a single module possible. A system's architecture therefore gets designed together with the org chart of whoever will build it and whoever will use it, not afterward. Before drawing modules, integrations or APIs, the useful question is who decides what and who answers to whom during the project: that map, not the chosen tool, is what the finished system will mirror. Ignoring this point is one of the easiest roads into technical debt, because fixing a fracture the organization has already baked into the code costs more than preventing it, and into a vendor lock-in that is really organizational lock-in wearing a technical disguise. Anyone who genuinely wants a unified system, with one version of the data that counts as the reference point (the territory covered in single source of truth), needs to settle who talks to whom in the company first: the technical architecture comes after, as a consequence of that decision, not a substitute for it.