Conway’s Law

Conway’s law is the observation that the structure of a system mirrors the structure of the communication in the organization that built it. Conway’s own statement of it: “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

It comes from a 1968 paper, “How Do Committees Invent?”, published in Datamation in April of that year — submitted to a management journal the year before and rejected. Worth knowing because the law is frequently cited as folklore, and the original is both older and more precisely worded than the paraphrases.

It is an observation, not an instruction

Read the sentence again for what it does not say. It does not tell you to organize teams around your intended architecture. It does not claim the resulting design is good. It says the design will copy the communication structure — a prediction about what happens, whether or not anyone intends it.

Note also that the mirror is of communication structure, not the org chart. Two teams on the same floor who talk constantly are one communication unit regardless of reporting lines; two teams in the same department who exchange tickets are effectively separate. Which is why an accurate application of the law starts by asking who actually talks to whom.

The practical consequence is that the interfaces in a system end up where the conversations were expensive. A component built by four groups in three time zones will have seams at the points where coordination was hardest — and those seams are often in the wrong place for the domain.

Two ways to use it

Because it is a prediction, the useful applications are diagnostic and strategic rather than prescriptive.

• Treat a mismatch as a predictable cost. Where team boundaries and system boundaries disagree, you can say in advance what will go wrong: a component owned by two teams accumulates conflicting changes and inconsistent conventions; a business capability split across three teams turns every feature into a coordination exercise. This is an audit you can run from a service list and a team list in an afternoon, and its output is a list of the places where delivery is slow for structural reasons rather than technical ones.
• Treat reorganization as a design tool with a long lead time. If the communication structure will be copied into the design, then changing team boundaries changes what the system can become — slowly, and at a cost no refactor matches. The implication is about sequence: decide the boundaries you want before a reorganization rather than discovering afterwards that the new structure argues for different ones.

Both are more useful than the slogan version, and both survive the fact that you usually cannot choose your organization freely.

Three ways it is misused

As a licence to copy another company’s topology. Adopting a published service architecture imports the communication structure of the organization that produced it. Their boundaries encode who talked to whom, in a company you do not have and at a scale you may not share.

As an argument for one service per team. The law says the design will mirror communication, not that each team should own exactly one deployable. A team can perfectly well own a coherent set of modules inside a single deployable — which is the case for a modular monolith — and a service count driven by headcount produces boundaries that match the staffing plan rather than the domain.

As a reason not to try. Conway’s law means our architecture is determined by our org chart treats a prediction as a fate. The prediction is about the default outcome; deliberate design, explicit interfaces, and investment in communication across a seam all change what the default would have been.

One boundary of the law’s usefulness is worth stating: it explains why boundaries land where they do, not where they should land. The question of where a boundary belongs is answered by data ownership and by meaning — a bounded context — and then compared with the organization to see what it will cost. How that comparison is done, and what a split charges either way, is worked through in Splitting the System Was the Easy Part.

Reference: Melvin E. Conway, “How Do Committees Invent?”, Datamation, April 1968.