Conway's Law

In 1968, Melvin Conway published a paper called How Do Committees Invent? with a single sentence that became the foundational observation of software architecture:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

Sixty years later, this is the most reliably observed phenomenon in software. It is also the most under-appreciated by engineering leaders: most architectural problems are organizational problems wearing a technical mask, and most "let's reorganize the code" projects fail because the underlying organizational structure has not changed.

This page is about what Conway actually said, why it works, and what to do about it — including the inverse maneuver (changing the org to get the architecture you want) that has become an industry practice.

What Conway Actually Meant

The claim is stronger than "teams write code that reflects their org chart." Conway's mechanism is:

Any two modules that interact must have an interface. That interface requires designers from both modules to agree. Agreement requires communication. Therefore the modules that exist correspond to the pairs of designers who communicate.

If three designers communicate, you get three modules with interfaces between them. If two of those designers stop talking, the interface between their modules stops being maintained — typically by congealing into an awkward static API or a single team taking over both sides.

The "law" is not normative; Conway was not advocating anything. He was observing that the information topology of an organization determines what designs are feasible and what designs collapse under their own communication weight.

The Practical Implications

Each of these follows directly:

Module Boundaries Track Team Boundaries

Code that one team owns end-to-end can be coherent. Code that requires two teams to coordinate every change becomes either tightly coupled (because changes are easy when communication is open) or stagnant (because the coordination tax is too high).

The corollary: if you want a module, you need a team for it. A module without a clear owning team becomes everyone's and no one's, accumulates cruft, and eventually becomes a coordination bottleneck.

Service Boundaries That Cross Team Boundaries Are Expensive

Microservices work when each service has an owning team and team-to-team communication is what API contracts mediate. When a single feature requires changes in three services owned by three teams, the coordination cost becomes the dominant tax.

This is why "we adopted microservices but a single feature still requires four PRs across four teams" is a common failure: the service boundaries do not match team boundaries, so the system has the cost of distribution and the cost of coordination at once.

Reorganizations Force Re-architectures

Merging two teams typically merges the code they own. Splitting a team typically splits a module. The system follows the org chart, not the other way around — and reorganizations that ignore this produce systems that are coherent on paper and incoherent in code.

Communication Patterns Show Up in the Code

A team that does design in a single weekly meeting produces tightly-coupled internal code (because everything is discussed together). A team that does design async produces more loosely-coupled code (because each component must be self-explanatory). Neither is better; they fit different problems.

The Inverse Conway Maneuver

If organization determines architecture, you can change the architecture by changing the organization. This is the Inverse Conway Maneuver: deliberately structure teams to produce the desired system architecture.

Examples:

• You want microservices? Structure teams as small, autonomous, end-to-end product squads owning a service each. Reduce dependencies between teams. Communication between teams becomes API negotiation, which gives you stable contracts.
• You want a modular monolith? Have one team or a small set of closely communicating teams. Internal modules can stay coherent because changes are easy to coordinate.
• You want a platform / product split? Have a platform team owning infrastructure and reusable components; have product teams consuming the platform. The interface between them is the platform's API.

The maneuver works because it is not fighting Conway's Law — it is using it. The organization is the lever.

The maneuver fails when:

• Org changes are nominal but reporting lines and incentives stay the same.
• Team boundaries are drawn but team autonomy is not (every decision still escalates).
• The desired architecture requires team boundaries that the business cannot support.

When the Architecture Fights the Org Chart

The most common failure mode is the inverse: the architecture you want does not match the org chart you have, and you try to bring the architecture into being through technical means alone. This never works. Symptoms:

• A "microservices migration" that produces 15 services owned by 4 teams. Each service-to-service interaction involves cross-team coordination. The system has microservices' costs without their benefits.
• A "platform team" that owns infrastructure but does not have product authority. Product teams route around it. The "platform" becomes a different name for "things that did not get done."
• A "shared kernel" library owned by no one. Changes accumulate. The kernel becomes the largest source of bugs.
• "Tiger team" projects that produce coherent designs nobody integrates because the receiving teams were not part of the design.

The cure is to align org chart and target architecture before writing code. If you cannot get the org change, do not pretend the architecture will work anyway.

Conway's Law and Bounded Contexts

Domain-Driven Design's bounded contexts are Conway's Law applied to domain modeling. A bounded context is a coherent unit of meaning — vocabulary, model, language. A bounded context that crosses team boundaries decays because no single team can keep the meaning consistent.

The natural shape is: one bounded context, one team. Multiple bounded contexts owned by one team is fine (a small team can hold several). One bounded context split across teams is fundamentally unstable; either it consolidates under one team or it fragments into separate contexts.

Implications for Engineering Leadership

If Conway's Law is real, several things follow that engineering leaders often resist:

• The architecture roadmap is downstream of the org chart. You cannot have a successful microservices migration with the wrong team structure. Plan the team structure first.
• Reorgs change architecture whether you intend them to or not. A merger of two product teams will collapse their codebases over time. An incoming VP who restructures will produce a new system shape.
• Hiring decisions are architectural decisions. Hiring a team means committing to owning a module. Hiring profile (frontend vs full-stack vs ML vs platform) shapes what kinds of components the team can own.
• Communication channels are architectural decisions. Putting two teams in the same chat channel, the same standup, the same OKR — these increase coupling between their components. Separating them decreases it.
• You should design the team topology, not just the service topology. This is the central thesis of the Team Topologies book.

What Conway Did Not Say

Worth noting what is not in the original paper:

• Conway did not say organizations should produce systems that mirror their structure — only that they will. He was describing, not prescribing.
• He did not say smaller teams are always better, or that microservices are right, or that any specific architecture is preferred. He was identifying a constraint that any architectural choice runs into.
• He did not say architects are powerless. The maneuver is real; you can shape the organization to shape the system.

The most common misreading is to treat "any organization will produce..." as fatalism. It is closer to a thermodynamic law — energy flows in predictable directions, but engineers can build pumps and turbines to redirect it.

Further Reading

• Conway, How Do Committees Invent? (Datamation, 1968) — the original. Six pages, eminently readable.
• Manuel Sousa, Team Topologies (2019) — the modern application of Conway's Law to team design. Most influential recent book in the area.
• Mel Conway's website (melconway.com) — short essays from Conway himself, expanding the original.
• Martin Fowler, Conway's Law — entry-level treatment with examples.
• Allan Kelly, Project Myopia — covers Conway alongside related observations about team and project structure.
• Adam Tornhill, Your Code as a Crime Scene — shows Conway's Law empirically via mining of code-and-team-change data.

Pre-commit Checklist

• For each major module or service in my system, can I name the single owning team?
• For each cross-team interaction, is there an explicit API/contract — or is the team boundary inside the code?
• Am I attempting an architectural change without a corresponding org change? If so, what does Conway's Law predict will happen?
• Are my bounded contexts owned by single teams? Contexts shared between teams will decay.
• For my microservices, do the service boundaries match team boundaries — or do features cross multiple teams' services?
• Have I considered restructuring the team first, and letting the architecture follow, rather than the other way around?