What is Conway's Law, and what does it predict about the relationship between an organization's communication structure and the systems it builds?
answer
- Conway 1968 — design copies communication structure
- Mechanism: cross-team coordination is expensive
- Real comms network ≠ org chart
- Four teams → four-pass compiler
- Descriptive forecast, not advice
basics
~20 sConway's Law says a system's structure ends up mirroring how the teams that built it communicate. Four teams building a compiler tend to produce a four-pass compiler, because each team's boundary becomes an interface in the software.
solid answer
~50 sConway's Law, from Melvin Conway's 1968 paper, states that any organization designing a system will produce a design whose structure is a copy of that organization's communication structure. The causal mechanism is cheap coordination inside a team versus expensive coordination across teams: work that requires constant negotiation gets pushed behind a stable, coarse interface, so team boundaries harden into module or service boundaries. It is descriptive, not prescriptive — a prediction about what will happen by default, not advice. Two practical consequences follow. First, you cannot ship an architecture that contradicts your org chart for long; the org will bend the design back. Second, if you want a particular architecture, changing team structure is a legitimate design lever (the Inverse Conway Maneuver). The key nuance: the relevant structure is the real communication network, not the formal reporting hierarchy.
go deeper
State the law and give the compiler example; say team boundaries turn into software boundaries.
Add the mechanism (coordination cost) and the distinction between communication structure and org chart; mention it's descriptive.
Discuss the feedback loop in both directions, distributed-monolith failure mode when architecture fights the org, and the Inverse Conway Maneuver as the deliberate use of it.
Frame it as a socio-technical design constraint: treat team boundaries, ownership, and coordination cost as first-class architectural decisions; discuss empirical evidence, its limits, and when to accept an org-shaped architecture rather than fight it.
## 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.
- Is Conway's Law about the org chart or about something else?About the actual communication structure — who must talk to whom, how often, and at what cost. Two teams that pair daily behave as one unit; two teams in the same department that exchange only tickets behave as two. Remote/time-zone/contract boundaries count as communication boundaries even when the org chart shows none.
- Does causation only run from organization to architecture?No — it's a feedback loop. Existing code dictates who must be consulted to change it, which reinforces the current team structure. That's why successful re-architectures are usually paired with a reorg; doing either alone tends to snap back.
- What evidence supports Conway's Law beyond anecdote?Empirical studies (notably on Microsoft components and on open-source projects with multiple contributing organizations) found organizational-structure metrics — ownership concentration, number of contributing orgs, org-chart distance between contributors — predicted post-release defects at least as well as code-complexity metrics.
Water flowing downhill carves channels along the easiest path. Team boundaries are the ridgelines: work flows around them, and over time the software erodes into exactly the valleys your org chart's ridges allow.