Conway's Law

Look closely at a large software system and you can often see the organization that built it. The same pattern appears beyond software, in products, processes and even customer experiences. Separate teams produce separate components, the boundaries between modules match the boundaries between departments and the awkward integrations sit exactly where two teams struggled to coordinate. This is not a coincidence. The structure of an organization determines who talks to whom, how often and how easily, and that pattern of communication ends up built into the product. Conway's Law gives this observation its name.

Computer programmer Melvin Conway introduced the idea in a 1968 paper, How Do Committees Invent?, writing that organizations which design systems are constrained to produce designs that are copies of their communication structures. Fred Brooks named it Conway's Law in The Mythical Man-Month, and later research, including studies at Microsoft and Harvard Business School, found evidence that product architecture tends to mirror organizational structure. In the 2010s, the idea gained new attention through the inverse Conway maneuver, which deliberately shapes teams to produce the desired architecture. For technology leaders, organization designers and product executives, Conway's Law is a reminder that structure and architecture decisions cannot be made separately.

Definition of Conway's Law

Conway's Law is the principle that the architecture of a system produced by an organization will reflect the organization's communication structure, because components are designed by groups whose interfaces with one another mirror the interfaces between those groups.

It is a core idea behind team topologies, an important consideration in organizational design for technology organizations and connects team structure to enterprise architecture.

How Conway's Law Works

Teams find it easier to coordinate internally than with other teams, so they tend to build components they fully own.

Where two teams must work together, the interface between their components reflects how well they communicate, with poor communication often producing awkward or brittle integrations.

Systems built by a single large team tend to become tightly coupled, while systems built by many independent teams tend to become modular.

As organizations change structure, systems often lag behind, leaving architecture that reflects an organization that no longer exists. Communication also follows geography and time zones, so teams in different locations tend to produce components with looser, more formal interfaces.

The Inverse Conway Maneuver

The inverse Conway maneuver turns the law into a design tool. Instead of letting team structure shape architecture by accident, leaders first decide the architecture they want and then shape teams to match it.

For example, an organization wanting independent services for search, checkout and payments might create a separate long-lived team for each.

The approach is closely linked to microservices, product-based team structures and platform teams that provide shared capabilities.

It works best when team boundaries are kept stable, since frequent reorganizations break the link between teams and the systems they own.

Importance of Conway's Law in Workforce and Operations

Conway's Law links structure to speed. Teams that own whole components can change them without waiting for others, which shortens delivery times.

It explains integration problems. Many technical issues are really coordination issues between teams, and they cannot be fixed by technology alone.

It also guides reorganizations. Changing team structure without considering existing systems can leave teams owning parts of components that they cannot change independently. The principle applies to business processes too, where handoffs between departments often show up as manual steps and duplicate data entry in the systems that support them.

Conway's Law and Financial Management

Misaligned team and system boundaries increase cost through coordination overhead, delays and rework at integration points.

Aligning teams to components or products makes it easier to assign technology costs to the business capabilities they support.

Reorganizing teams to match a target architecture has transition costs, which should be weighed against expected gains in delivery speed.

Long-lived teams that own systems tend to reduce maintenance costs because the knowledge stays in one place.

Common Challenges

Leaders often reorganize for business reasons without considering the effect on the systems teams own, creating unclear ownership.

Legacy systems built by past organizations resist change, so new team structures may still have to work around old boundaries.

Shared components that many teams depend on can become bottlenecks if no team clearly owns them.

The law is sometimes applied too literally, ignoring other influences on architecture such as technology choices and vendor products. Team cognitive load is another constraint, since a team can only own as much of a system as it can understand well.