Conway's Law: Why Your Products Mirror Your Org Chart

Conway’s law is the idea that whatever an organization designs ends up shaped like the organization itself. Melvin Conway put it this way in the April 1968 issue of the computing magazine Datamation: organizations that design systems are “constrained to produce designs which are copies of the communication structures of these organizations.”¹ A plain example: if three separate teams build a company’s website, one for products, one for orders and one for help, visitors tend to meet three sections that look and behave differently, joined only where the teams agreed to meet.

In a working paper from Harvard Business School that compared five matched pairs of software products, the product built by a loosely connected open-source community was more modular than its commercially built twin in every pair.² Other studies are more mixed, so the fair reading is a strong tendency rather than a law of physics.

Design the product and the teams together. Before you split a product or a service between teams, sketch who talks to whom; the gaps in that sketch are where customers will later feel the joins. How a group is set up feeds into what makes teams effective, and Conway’s law shows how far it reaches into what the team ships.

What does Conway’s law mean, in plain words?

Conway’s law says a product’s parts, and the connections between them, follow the groups of people who made them and the conversations between those groups. Melvin Conway’s 1968 paper argued that this holds for any designed system, from software to weapons to public policy.¹

In Conway’s best-known example, a contract research firm had eight people to write two compilers, programs that translate code into instructions a computer can run. It put five people on the COBOL compiler and three on the ALGOL compiler, and the COBOL compiler ran in five phases while the ALGOL one ran in three.¹ The work was split by people, and the product followed.

So when a product feels oddly divided, with a form that asks for the same details twice, look at the org chart before you blame the designers.

Who came up with Conway’s law?

Melvin Conway, a computer scientist and programmer, came up with Conway’s law. The Harvard Business Review rejected his paper, “How Do Committees Invent?”, in 1967 because he had not proved his thesis; Datamation published it in April 1968. The name spread through Fred Brooks, who cited the paper in his classic book on software projects, The Mythical Man-Month, and called the idea “Conway’s law”.³ Wikipedia’s account adds that participants at a 1968 national symposium on modular programming had already given it that name.⁴

Conway never meant it only for software. In a note added to his paper decades later, he points to how the structures of US governments shape their approach to poverty, housing, education and health care.¹ For managers, that breadth is the point: the law applies to any team that produces something with parts.

Why products end up shaped like the org chart

Products copy the org chart because every connection between two parts has to be agreed by the people who build them. Conway reasoned that if two parts of a system talk to each other, the groups that designed them must have negotiated how; if the groups never talk, the parts never connect. Talking is expensive, and the cost grows faster than headcount: Conway noted that the number of possible communication paths in an organization is roughly half the square of the number of people, so organizations restrict communication to get work done, often along the lines of command. That, he argued, is one reason why military-style organizations design systems that look like their organization charts.¹ The same arithmetic explains why each added person costs a team more coordination.

The software author Martin Fowler gives the everyday version: if you can easily talk to the author of some code, you understand it better, so your code is more likely to depend on theirs. He recalls an architect who, put in charge of six teams in different cities, announced that the system would have six major subsystems before knowing what they were. Separate floors are enough to cut communication, Fowler writes, and separate time zones cut it further.⁵

The chart on the wall is not the communication structure. Who sits together, shares meetings and overlaps in time zone decides where the seams in your product will fall.

Is Conway’s law true? What the studies found

Conway’s law holds up well inside companies and less consistently elsewhere. One of the best-known tests, by researchers at Harvard Business School and MIT in the US, found the mirroring pattern in every product pair it examined.²

The study

Moderate evidence

Five pairs of look-alike programs, one built in the open and one in-house

Alan MacCormack, John Rusnak and Carliss Baldwin compared products that do the same job but were built by very different organizations: open-source projects with contributors spread across many companies and countries, and commercial products built by a single firm. In all five pairs, from a spreadsheet to an operating system, the open-source product was significantly more modular. In the financial-software pair, a change to one file could on average affect about 8 percent of the open-source system, against about 47 percent of the commercial one.²

This is an observational studyobservational study: A study in which researchers record what people already do or are exposed to, rather than assigning anyone to anything. It can show that two things go together, not that one causes the other, because the groups being compared may differ in other ways as well.Full entry in the glossary, so it shows a match, not a cause. The authors say it fits two explanations: designs drift toward how their makers communicate, or open-source projects choose modular designs so strangers can contribute. They also note the small sample and the software-only setting.²

Other researchers measure the match directly. Marcelo Cataldo of Bosch’s research center and James Herbsleb and Kathleen Carley of Carnegie Mellon University, all in Pittsburgh in the US, studied one company’s large software product, built by several teams across three locations. When developers coordinated with the colleagues whose code their work depended on, change requests took about a third less time to resolve. They call this match socio-technical congruence, and their data come from a single system.⁶

The wider evidence is mixed. Lyra Colfer and Carliss Baldwin reviewed 142 studies across industries and found that 70 percent of the descriptive studies of industries and firms strongly supported mirroring, while most descriptive studies of open collaborative projects did not.⁷ A 2021 study of 25 large open-source projects, by researchers based in the US, Germany and the Netherlands, found no link between how well communication matched technical dependencies and bugs or churn, a measure of how much code gets changed.⁸

Strictly read, Conway’s law describes a correspondence and does not say which side causes the other; commentators argue both directions.⁴ For a manager inside a company, with formal teams and a chain of command, the safer working assumption is that the product will tend to copy the teams unless you plan otherwise. In open, online collaboration, where anyone can read the code, the mirror may bend.

Conway’s law outside software: services, reports and websites

Conway’s law applies wherever a group designs something with parts, including services, reports and websites. Conway’s own paper includes two military services, told to develop a common weapon system, that after great effort produced a copy of their organization chart.¹

A 1997 paper by the usability researcher Nigel Bevan, quoted on Wikipedia, observed that organizations often build sites whose content and structure mirror their internal concerns rather than what users need.⁴

Services follow the same pattern. Lou Downe, a former Director of Design for the UK government, lists among 15 principles of good service design that a service should not unnecessarily expose users to the internal structure of the organization providing it.⁹ In an illustrative case, a bank customer reports a lost card, then repeats the story to the fraud team and again to the card team, because each step belongs to a different department.

Reports do it too: a quarterly report with one chapter per department answers “what did each team do?” rather than “how are customers doing?”.

The evidence here is thin: Colfer and Baldwin note that service industries are underrepresented in the research, which leans heavily on software, cars, chips, computers and aircraft.⁷ The examples outside software are well described, but they are not well measured.

What is the inverse Conway maneuver?

The inverse Conway maneuver is the deliberate use of Conway’s law: you change how teams are organized so that their communication pattern encourages the system design you want. According to Martin Fowler, Jonny LeRoy and Matt Simons coined the term in the Cutter IT Journal in December 2010.⁵ The consultancy Thoughtworks put the maneuver in its Technology Radar in 2014, rated “trial”, meaning worth pursuing on a project that can handle the risk.¹⁰

The best-known development is the 2019 book Team Topologies by Matthew Skelton and Manuel Pais. In an interview with InfoQ, they describe the sequence: first decide on the architecture that lets changes flow quickly, then form teams whose communication paths match it, one service or business area at a time, with no guarantee of good delivery.¹¹ Their model centers on stream-aligned teams that own a slice of the business from start to finish, with no handoffs to other teams.¹²

Outside software, a hypothetical hospital that wants one smooth discharge process might give one ward team ownership of it, instead of splitting it between nursing, pharmacy and transport queues.

How does Conway’s law apply to microservices?

Microservices, small software services that can be changed and released independently, are where Conway’s law is most often applied on purpose. James Lewis and Martin Fowler’s 2014 description of the style argues that services should be built around business capabilities by cross-functional teams, not split by technical layer. Their reasoning is Conway’s law at work: when a company has a user-interface team, a server team and a database team, even a simple change becomes a cross-team project needing time and budget approval, so teams quietly put logic wherever they have access.¹³ Fowler later wrote that he sees microservices as primarily a tool for structuring a development organization.⁵

Two cautions follow. By Conway’s reasoning, splitting a system into services without changing the teams keeps the old communication pattern, so expect the old coupling to creep back. And for a small group the advice runs the other way: Fowler argues that a dozen or two people can talk informally and will naturally build a single connected system, which is fine.⁵ Where teams do share an interface, agree who owns it; a RACI matrix for shared work is one way to write that down.

What a reorganization cannot fix

A reorganization cannot quickly undo a design that already exists. Martin Fowler warns that if you have a system with a rigid architecture, changing the organization is not an instant fix and is more likely to create a mismatch between teams and code that slows further work.⁵

Myth

Reorganize the teams and the system will soon follow the new chart.

Fact

A rigid system keeps its old seams, and new teams end up fighting code shaped by the old organization. Change teams and code together.

Mirroring can also trap a successful company. Colfer and Baldwin describe a mirroring trap: firms and industries organized tightly around the current product can miss or fail to adopt new designs that cut across their boundaries, as in the fragmented US construction industry. Their suggested remedy is partial mirroring: let what people know reach wider than the part they are responsible for.⁷

Conway himself drew the same conclusion in 1968. Because the first design is almost never the best, the organization has to stay flexible enough to change with it, and design teams should be organized around the need to communicate.¹

Putting Conway’s law to work

Conway’s law is most useful as a habit: check that teams and design agree before either is locked in. The steps below draw on the sources above; nobody has tested them together.

Map the real communication

List the parts of your product or service, then note which teams build each part and how often they talk. Parts that must work closely together but whose teams rarely talk are where friction will show up.

Decide the design and the teams together

Sketch the team boundaries in the same meeting as the technical boundaries, then change one service or business area at a time. Fowler’s advice is to split the system and the organization together, throughout the life of the enterprise, in small steps.⁵

Before you redraw a product or a team

• List the main parts of the product or service
• Note which team owns each part
• Mark which teams talk each week
• Circle parts that depend on each other but whose teams rarely talk
• Sketch the team change and the design change side by side
• Pick one area to change first and agree how you will spot new friction

The bottom line

What your organization builds will tend to follow who talks to whom, so treat team design as part of product design. Inside companies the evidence for this mirroring is good; in open, online projects it is weaker. Use the inverse Conway maneuver to shape teams around the design you want, but change an existing system and its teams together, one area at a time.