What is Conway's Law, and what does it predict about the relationship between an organization's communication structure and the systems it builds?

## The statement Melvin Conway, in a 1968 paper ("How Do Committees Invent?"), wrote: > Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. "System" here is broad — software, hardware, documents, processes. "Communication structure" means who actually talks to whom to get work done, at what cost and frequency. That is **not** the same as the org chart: two teams in different departments who pair daily are, for Conway purposes, one unit; two teams under the same director who only exchange tickets are two units. ## Why it happens (the mechanism, not magic) Designing an interface between two components requires agreement. Agreement requires communication. Communication has a cost that rises sharply when it crosses a team, a time zone, a language, a company, or a contract. - **Inside a team**, coordination is nearly free: you can refactor across a boundary in an afternoon, ask a question in seconds, and change a shared data structure without a meeting. So teams produce highly-coupled, fine-grained internal designs — and they keep them, because that's cheap. - **Across teams**, coordination is expensive. Engineers naturally minimize it by freezing the boundary: define an API, a message schema, a file format, and then stop talking. The frozen boundary is exactly a module boundary in the delivered system. So the shape of the delivered system converges on the shape of the cheap-communication clusters. Conway summarized the causal core himself: the design that gets built is the one that can be *negotiated* by the people building it. A second reinforcing mechanism is **homomorphism of decision authority**: a decision that spans two teams needs an escalation to the common manager; teams avoid such decisions; the avoided decisions become the untouched seams of the architecture. ## Classic illustrations - Conway's own example: four groups assigned to a compiler produced a four-pass compiler. - A company with separate frontend, backend, and DBA teams reliably produces a three-tier architecture with a service layer and a stored-procedure layer, whether or not that's the best design. - Merged companies produce integration layers exactly where the two former companies' boundaries were. - Outsourcing a subsystem produces an unusually rigid, over-specified API around that subsystem — because the communication cost across a contract is the highest of all. ## Descriptive, not prescriptive Conway's Law is often quoted as advice ("organize your teams around your architecture!"). It isn't advice; it's a *forecast*. Its normative uses are derived: 1. **Diagnostic** — if your architecture has a seam nobody can explain technically, look for an old team boundary. Architecture archaeology often finds a reorg, an acquisition, or a departed contractor. 2. **Predictive** — before a reorg, ask what architecture that org will produce in 12 months, because it will. 3. **Design lever (Inverse Conway Maneuver)** — deliberately restructure teams so the *desired* architecture is the one that is cheap to build, then let Conway's Law work for you rather than against you. ## Failure mode: fighting Conway's Law Declaring a target architecture that cuts against the org's communication structure produces predictable pathology: - Teams split a service on paper but keep a shared database, because the schema change needs both teams — a **distributed monolith**: microservice deployment cost with monolith coupling. - "Shared ownership" of a module in practice means slow, low-quality changes, since every change needs cross-team negotiation. - Architects write documents; the code drifts back toward the org shape within a couple of quarters. ## Important nuances and caveats - **Direction of causation runs both ways.** Once code exists, its structure constrains who *must* talk to whom (you can't change a module without its owner). So an inherited architecture also reshapes the org. Some authors call this the "Conway feedback loop." That's why an architecture migration and a reorg usually have to happen together. - **The empirical support is real but partial.** Studies of Microsoft and open-source projects found organizational metrics (number of contributing orgs, ownership churn, edit distance in the org chart) predicted defect-proneness better than many code metrics. That supports the *coupling* claim more precisely than the strong "exact copy" claim. - **It's a strong tendency, not a law of physics.** Very small orgs, very high-communication cultures, or a single dominant architect can produce designs that don't mirror the org — for a while. As headcount grows, the tendency reasserts itself. - **Communication structure includes tooling and process.** A shared monorepo with company-wide code review lowers cross-team communication cost and therefore permits finer-grained cross-team designs; a strict ticket-based handoff process raises it and forces coarser boundaries. ## What a good answer contains Name Conway (1968), state the law, explain the *mechanism* (communication/coordination cost), stress "real communication network, not org chart", note it is descriptive, and mention that the Inverse Conway Maneuver is the deliberate exploitation of it.