Conway’s Law

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” — Melvin Conway, 1967

The Claim

Software systems inherit the shape of the teams that build them. A project run by four teams will produce a system with four major subsystems, one per team, with the interfaces at the team boundaries. The product reflects the org chart, not because anyone intends it to, but because communication is cheaper inside a team than across one, and the path of least resistance routes functionality through team ownership.

Why It Holds

The mechanism is sociological, not technical. Two people on the same team can sketch an interface at a whiteboard in ten minutes; two people on different teams schedule a meeting, write a design doc, negotiate ownership, and ship the interface as part of a quarterly plan. The cost differential compounds: within a team, hundreds of small decisions; across teams, a handful of large ones that calcify into permanent contracts.

The practical consequences are predictable:

• Monoliths emerge from co-located single teams.
• Microservice architectures emerge from companies with many independent teams.
• Hairball dependencies emerge from cross-team projects with no single owner.
• Mysterious bottlenecks often correspond to the single team everyone routes through.

Inverse Conway Manoeuvre

Since architecture will mirror org chart, design the org chart you want and the architecture will follow. This is now standard practice at large platform organisations: Amazon’s two-pizza teams, Spotify’s squads/tribes/guilds model, and the general “platform / product / infra” trichotomy are all applied inverse-Conway. You cannot decree a microservice architecture; you must restructure teams so that microservices become the path of least resistance.

In This Wiki

• Founder mode explains Conway’s Law in reverse. Founder-led companies tend to produce more integrated, less modular systems because founders flatten communication hierarchies. paul-graham describes “skip-level engagement” — founders talk directly to anyone, which removes the communication boundaries that manager-mode organisations impose. The product becomes less siloed as a second-order effect.
• Connects to brooks-law. Brooks assumed fixed organisational structure and showed that adding people slows projects down; Conway explains why the cost is so high — each new person multiplies the communication graph and warps the architecture.
• Connects to densities-of-excellence. If the highest-performing teams cluster together, their systems will mirror that clustering — one tight product rather than a disparate suite.
• Connects to extractive-institutions vs. inclusive-institutions. At civilizational scale, the same logic applies: the “architecture” of the economy mirrors the power structure of the institutions. Extractive institutions produce extractive architectures (monopolies, rents). Inclusive ones produce distributed, competitive markets. Conway’s Law as political economy.
• Implied by bus-factor. Bus factor is the extreme case of communication-bottleneck risk: when one person is the only bridge between two parts of the system, Conway’s Law has produced a single-point-of-failure architecture.

Limits

Conway’s Law is descriptive, not prescriptive. Systems that fight the org chart — unusual architectures imposed on conventional teams, or vice versa — are possible but expensive, because every cross-boundary interface becomes high-friction. The question is not “can we escape Conway’s Law?” (you can’t for free) but “what communication structure is worth the architecture we want?”

Sources

• source—laws-of-software-engineering — The headline law in the Teams cluster.
• Melvin Conway, “How do Committees Invent?” (Datamation, April 1968) — original paper.