Symptom

The service has four layers. Nobody designed four layers. There were four teams.

Or the version that arrives in a postmortem: the outage happened at the boundary between two services, in the retry logic, because each side assumed the other owned the deduplication. Both teams were right about their own component and neither had ever been in a room with the other.

Or the one that costs the most and gets noticed the least: the API is ugly in exactly one place, and the ugliness maps precisely to the quarter when the frontend group reported to a different VP.

You have been reading these as management failures. They are, but they are also the most reliably predictive regularity in software engineering, and it was written down in 1968.

Statement

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Conway’s own phrasing, and the word constrained is doing more work than the popular paraphrase (“systems mirror org charts”) preserves.

There is a homomorphism from the organization’s communication graph to the system’s dependency graph. If two components must interface, their authors must communicate; where authors do not communicate, no clean interface appears.

Note the direction. The claim is not that the org chart determines the architecture — it is that the communication structure does, and the org chart is merely its most legible approximation. Two teams on different continents with a shared on-call rotation and a daily sync communicate more than two teams on the same floor under different VPs, and the architecture will show it.

This is [empirical], and the tag is the honest one. There is no proof.

Argument

There is no proof, but there is a mechanism, and the mechanism is why this regularity is stable rather than anecdotal.

Step one: a design is a communication artifact. To specify an interface between components $A$ and $B$, someone must decide what crosses it — types, errors, ordering, ownership of retries, who validates what. That decision is information that must exist in both authors’ heads. There is no other way for the interface to be coherent.

Step two: communication is expensive, and superlinearly so. Coordinating $n$ people has on the order of $\binom{n}{2} = n(n-1)/2$ potential channels. Organizations respond by not paying: they draw boundaries, and inside a boundary communication is cheap and constant, and across one it is scheduled, lossy, and rationed.

Step three: interfaces form where communication is cheap and calcify where it is not. Within a team, an interface can be renegotiated in an afternoon, so components get refactored until the boundary sits where it belongs. Across a boundary, changing an interface costs a meeting, a migration plan, and possibly a quarter — so the first interface anyone wrote is the one you keep, whether or not it was right.

Step four: so the architecture converges on the communication graph. Not because anyone chose it, but because every other architecture requires coordination the organization is not paying for. The pressure is continuous and nobody has to agree with it for it to win.

The mechanism also predicts the exceptions, which is the test of a mechanism rather than a slogan. Where an organization does pay the coordination cost — a strong architecture review, one author across two teams, a mandated shared interface — Conway’s law is locally suspended. It just gets expensive, and it reverts the moment the expenditure stops, which is why architectures decay after a reorg.

The evidence. MacCormack, Rusnak, and Baldwin (2012) compared matched pairs of systems built by tightly-coupled commercial organizations against loosely-coupled open-source ones, and found the open-source products significantly more modular — the same product category, different communication structures, different architectures. Microsoft’s 2008 study of Windows Vista found organizational metrics (how many engineers touched a binary, how far apart in the reporting hierarchy) predicted post-release defects better than code metrics like churn, complexity, or coverage. That is the strongest form of the claim available without a proof: the org chart out-predicts the code.

Forbids

Since this is empirical, “forbids” means “reliably fails in practice,” not “is impossible.” That distinction is the honest one and it matters here.

An architecture that ignores the org chart, surviving contact with delivery. You can draw it. You cannot staff it. The design will drift toward the communication structure over the following year, component by component, and each individual drift will look like a reasonable local decision.

Microservices from a monolithic organization. If every change still requires sign-off from one central team, splitting the deployable units yields a distributed monolith: all the coordination costs of the monolith, plus network partitions. The communication structure did not change, so the architecture did not change. Only the topology of the failure modes did, and for the worse.

Clean interfaces between teams that do not talk. The interface will exist, because something must compile. It will be a leaky pass-through of whichever side wrote it first, and the semantics — who retries, who deduplicates, what an error means — will be undocumented and discovered in an incident.

Reorganizing without expecting architectural change. The reorg is an architectural change. It has been applied to the system already; the code just has not caught up yet.

Does not forbid

It does not say the org chart determines the architecture, and taking it that way is what produces the cynical version. Communication structure is the variable, and it is only correlated with the formal hierarchy. Two teams with a shared on-call, a common design doc, and a weekly review are one communication node regardless of who they report to. Conway is not a claim that you are helpless; it is a claim about which lever works.

It does not forbid a good architecture from a badly-shaped organization. It prices one. Linux has a famously monolithic kernel built by thousands of loosely-connected contributors, which is close to the opposite of what a naive reading predicts, and it works because the maintainer hierarchy and the subsystem boundaries were deliberately aligned — an inverse maneuver run for thirty years. The mechanism was paid, not evaded.

It does not mean microservices are wrong, which is the misapplication doing the most damage right now. “Conway’s law says you need one team per service” has been used to justify splitting a twelve-person company into nine services, and the result is nine deployment pipelines maintained by people who all sit at the same table. The law says the architecture will mirror the communication structure. For a small, high-bandwidth team the mirrored architecture is a monolith, and building one is the Conway-compliant answer, not a failure of nerve. The law is symmetric and people only ever quote the half that recommends splitting.

It does not license the fatalist reading. “Conway’s law means our architecture is determined by the org chart, so there is no point arguing about design” is the most common way this gets deployed in a meeting, and it inverts the paper’s purpose. Conway’s own closing point is that because the homomorphism holds, the organization is a design tool. The law says where the lever is; it does not say the lever is nailed down.

It does not predict the quality of the resulting design. It predicts the shape. A well-structured organization produces a well-structured system that may still be slow, wrong, or solving the wrong problem. Conway constrains modularity, and nothing else.

Boundary

  • The inverse Conway maneuver. Since the homomorphism runs from communication structure to architecture, change the former to get the latter: decide the architecture, then organize teams to match it, and let the pressure work for you. This is the entire operating premise of Team Topologies and of Amazon’s two-pizza teams. It is the most valuable practical use of the law and the one most often stated as if it were the law itself. The caveat is real though: you are betting on an architecture before you have built it, and the organization is much harder to reorganize than the code once you are wrong.
  • Where it weakens. Very small teams (everyone talks to everyone, so the communication graph is complete and constrains nothing), and systems where one architect writes all the interfaces. Both are the same escape: the coordination cost has gone to zero, so the mechanism has nothing to push against. Both stop applying at the size where they stopped being true, which is usually around a dozen people and is noticed about a year late.
  • Where it strengthens. Long-lived systems, multiple locations, high turnover, and anywhere interfaces are expensive to change — public APIs, on-disk formats, protocol versions. Hyrum’s law (T091) is the reason those become permanent, and Conway’s is the reason they landed where they did. The two compose badly and predictably: Conway puts the seam in the wrong place, Hyrum welds it shut.
  • The measurable version. Socio-technical congruence (Cataldo et al.) makes this quantitative: measure the coordination the code requires against the coordination that actually happens, and the gap predicts defects and delay. That turns Conway from an aphorism into an instrument you can point at a repository, which is the honest answer to “empirical, so what do I do with it.”