Conway's law and the shape of organisations

What Conway actually said

In April 1968 the magazine Datamation published "How Do Committees Invent?" by Melvin Conway, a computer programmer and consultant. Its conclusion is the sentence now known as Conway's law: organisations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. The name came later: Fred Brooks cited the paper in The Mythical Man-Month (1975) and called the idea Conway's law.

Conway's argument is more precise than the slogan. A system is made of subsystems connected by interfaces. For two subsystems to connect, the people designing them must have negotiated and agreed that interface, so they must have communicated. If the designers of two subsystems do not communicate, there is no interface for them to agree on. There is therefore a structure-preserving correspondence (Conway used the mathematical term homomorphism) between the graph of the system and the graph of the organisation that designed it. His example: a contract research organisation had eight people to write a COBOL and an ALGOL compiler. Five were assigned to COBOL and three to ALGOL. The COBOL compiler ran in five phases; the ALGOL compiler in three.

Two further points from the paper are often forgotten. First, Conway was explicit that "system" is meant broadly: it applies to any designed thing, not only software. Second, his practical conclusion was about flexibility. Because the first design is rarely the best one, and because an organisation tends to fix its structure early (once teams are formed, the design is already partly decided), he argued that design organisations should be kept lean and flexible and organised according to the communication the design actually needs.

The evidence: the mirroring hypothesis

For decades Conway's law was supported mainly by anecdote. Since the 2000s researchers have tested it, usually under the name mirroring hypothesis: the technical dependencies in a product will match the organisational ties (communication, co-location, employment) among the people who build it.

The best-known software study is by Alan MacCormack, Carliss Baldwin and John Rusnak, published in Research Policy in 2012 as "Exploring the duality between product and organizational architectures: a test of the mirroring hypothesis". They compared matched pairs of products with similar functions, one built by a tightly coupled organisation (a commercial firm with a co-located team) and one by a loosely coupled organisation (a distributed open-source community): for example, two financial management packages, two word processors, two databases, and Linux compared with commercial operating-system kernels. They measured modularity by propagation cost, the average share of a system's files that a change to one file can affect directly or indirectly. In every pair the product from the loosely coupled organisation was more modular, and in the most extreme pair the difference was several-fold. The authors interpret this as evidence that distributed teams, who cannot easily coordinate, are pushed towards designs that need less coordination.

A Microsoft Research study of Windows Vista by Nachiappan Nagappan, Brendan Murphy and Victor Basili (2008) approached the question from the quality side. Metrics describing the organisation that built each binary (how many engineers touched it, how many had left, how far apart in the management hierarchy the contributors sat) predicted which binaries were failure-prone better than conventional code metrics such as churn, complexity, coverage and dependencies.

The evidence is not unanimous, and the honest summary matters. A 2016 review of 142 empirical studies by Lyra Colfer and Carliss Baldwin found mirroring common in studies of industries and firms, but not universal, and found that studies of open collaborative projects often did not support it, presumably because shared code repositories, issue trackers and open discussion let distributed contributors coordinate without the usual organisational ties. Mirroring is a strong tendency, not a law of physics, and good tools and practices can partly break it.

Communication paths and why team size matters

A group of n people has n(n − 1) / 2 possible one-to-one communication paths. The number grows roughly with the square of the group: doubling the team quadruples the paths. Brooks used the same arithmetic to explain why adding people to a late project makes it later: each newcomer must be trained and adds new paths that everyone must maintain.

Architecturally, the arithmetic explains two things. First, a single team cannot grow indefinitely and still keep a shared understanding of its code; past a certain size it fragments into informal sub-groups, and by Conway's law the code fragments along the same lines, whether or not anyone designed those seams. Second, the number of paths between teams matters as much as within them: if every team must talk to every other team to ship a change, the system's structure is effectively one large, coupled unit, however many services it has.

The inverse Conway manoeuvre

If organisations tend to produce systems that mirror their structure, you can use the tendency deliberately: design the team structure and communication paths for the architecture you want, and let the system grow into that shape. Jonny LeRoy and Matt Simons named this the inverse Conway manoeuvre in an article in the Cutter IT Journal in December 2010, and it has since become a standard technique in microservice and platform programmes.

In practice it means deciding the intended boundaries first (for example, ordering, payments, delivery tracking and restaurant onboarding as separate services), then forming one long-lived team around each, giving it ownership of the code, data and deployment pipeline, and arranging that teams interact mainly through published APIs and events rather than shared code or shared databases. Where cross-team contact is genuinely needed, make it explicit: a platform team offering a self-service product, an enabling team helping for a limited time.

The manoeuvre has limits. It works with the grain of an existing system only slowly: reorganising teams does not restructure a tightly coupled codebase, and for a while the new teams will be fighting the old architecture. Martin Fowler notes that it cannot quickly fix a rigid existing system. It also assumes you know the right boundaries; if you draw them wrongly and then harden them into team structures, Conway's law will faithfully reproduce the mistake and make it expensive to change. That is why teams often start with a modular monolith and move boundaries before making them organisational.

Team cognitive load

Conway's law tells you that team boundaries become system boundaries. A second constraint tells you how big each team's part can be. Team cognitive load, a concept Matthew Skelton and Manuel Pais brought into software organisation design in Team Topologies (2019; second edition 2025), is the total amount a team must hold in its heads to build, run and change what it owns: the business domain, the code, the infrastructure, the tools, the on-call duties.

They borrow from psychology the distinction between intrinsic load (the inherent difficulty of the task, such as understanding the domain), extraneous load (effort imposed by the environment, such as a manual deployment procedure or an obscure build) and germane load (the effort of learning that improves future work). The design goal is to minimise extraneous load, for example through platforms and automation, so that capacity goes to the intrinsic and germane kinds.

For architects the consequence is direct. A service or component boundary should give its owning team a part of the system it can fully understand. If a team owns twelve services across four domains, the team is overloaded, and either quality, speed or on-call health will suffer, however clean each service's code. Conversely, a domain so complicated that no stream-aligned team can absorb it (a pricing engine with actuarial models, a video codec) may justify a specialist team and a clear boundary around its subsystem.

Letting team structure shape boundaries

Taken together, these ideas give architects a set of working rules:

Align boundaries with team ownership. Every module, service, data store and pipeline should have one owning team. Shared ownership in practice means no ownership, and the code will reflect whatever the last contributor needed.

Minimise the communication each change needs. A boundary is in the right place if most changes to a business capability can be made, tested and deployed by one team. Watch for changes that routinely need three teams to coordinate: they show that the system's structure and the team structure disagree.

Make cross-team interfaces explicit and stable. Interfaces between teams deserve versioning, documentation and contract tests; interfaces within a team can stay informal and change freely.

Revisit both together. Reorganisations are architecture decisions; architecture decisions are organisational decisions. An architect who is not consulted on team changes, or a manager who reorganises without considering the code, is ignoring a force that will act regardless.

The patterns for team types and interaction modes, and how to evolve them, are covered in Team Topologies and socio-technical design.