Skip to main content
Category: Laws
Type: Organizational Theory
Origin: Programming, 1957, Melvin Conway
Also known as: Conway’s Corollary
Quick Answer — Conway’s Law states that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. Formulated by Melvin Conway in 1957, this principle explains why software architecture often reflects team structure, why siloed organizations create siloed systems, and why cross-functional teams can produce more integrated solutions.

​
What is Conway’s Law?

Conway’s Law is a fundamental principle in software engineering and organizational design that describes the relationship between an organization’s communication structure and the systems it creates. The law states that any system is constrained to mirror the communication patterns of the organization that built it.
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin Conway
The intuition is straightforward: people build what they can communicate about. If your engineering team is organized into separate frontend and backend groups with minimal communication between them, your system will likely have a corresponding separation—with a defined API boundary between the two. If teams are organized around business capabilities, the system tends to reflect that structure too. This law has profound implications for how we design organizations, architect systems, and think about organizational change.

​
Conway’s Law in 3 Depths

  • Beginner: Recognize that team boundaries often become system boundaries. If you want different system boundaries, you need different team structures.
  • Practitioner: Use Conway’s Law intentionally—create team structures that match the desired system architecture. This is sometimes called “inverse Conway Maneuver.”
  • Advanced: Understand that Conway’s Law works at multiple scales—departments, teams, and even individual developers have personal “architecture” that shows up in their code.

​
Origin

Melvin Conway (born 1934) is an American computer scientist and programmer who introduced this concept in 1957 through a paper titled “How Do Committees Invent?” The paper was later shortened and republished in 1967 as “Conway’s Law.” Conway’s insight came from observing how committees and organizations designed systems. He noticed that the structure of the resulting system inevitably reflected the structure of the group that created it. This observation has since been validated countless times across industries and decades. The phrase “Conway’s Law” was coined by author Norman F. Naiman in a 1968 publication, though the principle itself is entirely Conway’s.

​
Key Points

1

Team structure becomes system structure

The boundaries between teams tend to become the boundaries between system components. If you want to change your system architecture, start by changing how your teams are organized.
2

Communication bottlenecks become system bottlenecks

If two teams rarely communicate, the interface between their system components will be poorly designed, under-documented, and hard to change.
3

Cross-functional teams enable integrated solutions

Teams that include diverse expertise (design, backend, frontend, operations) can produce more holistic systems than siloed groups.
4

The law works in reverse too

System architecture can constrain organizational options. Legacy systems often perpetuate old organizational structures long after they’ve become obsolete.

​
Applications

Organizational Design

When designing new systems or restructuring, align team boundaries with desired system boundaries. This is the “inverse Conway maneuver.”

Architecture Planning

Before designing system architecture, consider the organizational architecture. What teams exist? How do they communicate? This reveals what architecture is actually achievable.

M&A Integration

After mergers or acquisitions, realize that integrating systems requires first integrating organizations. The old team structures will resist new system architectures.

DevOps Transformation

DevOps and platform engineering initiatives often fail because they ignore Conway’s Law. You cannot have DevOps culture with Ops and Dev in separate reporting chains.

​
Case Study

​
The MIME Protocol

In 1974, Melvin Conway wrote a famous memo (later called “Conway’s Corollary”) predicting what would become of a proposed federal data-sharing standard. He wrote: “If a federal agency data-processing project is sufficiently important, the resulting system will have a federal-agency-like structure.” This prediction was famously validated when the IETF developed the MIME email standard. Despite being a technical standard, MIME reflected the organizational structure of the companies that created it. Each company’s email system had its own quirks, and the standard essentially encoded these organizational differences into a technical protocol. The lesson: when multiple organizations collaborate on a system, the final design reflects all their communication structures—which is often a patchwork of legacy patterns.

​
Boundaries and Failure Modes

When the principle doesn’t apply:
  • Strong architectural leadership: A highly influential architect or CTO can sometimes impose a system structure that differs from the organizational structure, at least temporarily.
  • External constraints: Regulatory requirements, customer mandates, or legacy system integration can override organizational influence on architecture.
  • Small teams: Very small teams (under 5-8 people) can maintain informal communication that doesn’t impose rigid structural constraints.
Common misuses:
  • Using Conway’s Law as an excuse: Some teams claim they “can’t” create certain architecture because of team structure—without trying to change the structure.
  • Ignoring it during reorganization: Organizations often restructure without considering the impact on existing systems, leading to architecture-team misalignment.
  • Over-applying the law: Not every code module reflects a specific person; some code is genuinely generic.

​
Common Misconceptions

Wrong. The law describes a fundamental organizational phenomenon that applies to any system designed by groups—buildings, processes, policies, and even social structures.
Wrong. It’s about communication patterns, not reporting lines. Two teams that report to the same manager but don’t talk to each other will still create siloed systems.
Wrong. The law is descriptive, not prescriptive. If you have the right team structure, Conway’s Law helps you create coherent systems. The key is intentional design of both organization and system.

Microservices

An architectural style where systems are decomposed into small, independent services—often reflecting small, independent teams.

Team Topologies

A framework for organizing teams around system architecture, explicitly using Conway’s Law intentionally.

Cross-Functional Teams

Teams that include all skills needed to deliver value—reducing hand-offs and enabling integrated solutions.

API Design

The interface between system components often mirrors the communication boundary between teams.

Bounded Context

In domain-driven design, a boundary that separates domain models—often aligned with team ownership.

Architecture Governance

Mechanisms for ensuring system architecture aligns with organizational goals and technical standards.

​
One-Line Takeaway

Remember: your system’s architecture will reflect your organization’s communication structure—design your teams intentionally if you want a specific system architecture.