There is a story about a company where three teams built a program together, and the finished program turned out to be split into exactly three chunks. No one had decided to do it that way, yet the way the teams were divided became the shape of the software itself.
The observation that the communication structure of the organization designing a system is reflected directly in the structure of that system is called ‘Conway's law.’ Among developers, it is also often quoted as “Look at the org chart and you'll see the software architecture.”
In this article, we will look in turn at where Conway's law came from, why it happens, what forms it actually takes, and how to turn the law around to your advantage.
Understanding Conway's Law
Where Did Conway's Law Come From?
The law is named after the American computer scientist Melvin Conway. In 1967 he wrote a paper titled “How Do Committees Invent?”, which, after being turned down by a business magazine, was published in 1968 in the computer magazine Datamation.
In the paper, Conway argued that “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” Here, ‘system’ referred broadly not just to software but to anything people design together.
The person who made this idea widely known under the name ‘Conway's law’ was Frederick Brooks. He introduced the observation in his 1975 book The Mythical Man-Month, regarded as a classic of software development, and since then Conway's law has become something like common sense in development practice.
Why Does an Organization's Shape Show Up in Its Design?
Because a large system cannot be built by one person alone, many people and teams divide up the work. Dividing the work means deciding where the parts fit together, that is, the interfaces, and deciding those interfaces requires the people in charge to talk to one another.
But conversations between people do not happen equally everywhere. Within the same team, you can ask questions and make fixes at any time, but with another team or department, you have to schedule meetings and exchange documents. So where conversation is easy, things are bound tightly together, and where it is hard, they are split by rigid boundaries.
In the end, a system's boundaries tend to be drawn where it is easy for people to communicate rather than where they would fit best technically. Conway's law is less a problem caused by a lack of will on the designers' part than a natural result of the way people work together.
Over time, these boundaries harden. Each part that has been split off gets its own team, and as each team tries to protect its share, changing the structure ends up requiring changing the organization as well. That is why people say that the older a system is, the more the traces of the company's past reorganizations remain in it like fossils.
How Conway's Law Shows Up
A common example is a company website. Visitors think they are looking at one company's site, but as they move from menu to menu, the design and tone often differ from department to department. That is because the site was organized around the company's internal departments rather than around customers' needs.
Something similar happens in large projects involving several companies. When each contractor builds its assigned part separately, each part works well on its own, but problems often surface where they connect, such as mismatched data formats or the same function being built twice. The more boundaries there are, the more time and money it takes to fill the gaps between them.
The law has also been confirmed by research. In 2012, researchers at Harvard Business School compared software products that perform the same function and found that products built by open-source developers scattered across many places had a more modular structure than products made by company teams working closely together. The researchers saw this as evidence for the ‘mirroring hypothesis,’ which holds that organizations and products resemble each other.
Turning Conway's Law Around
If Conway's law cannot be avoided, another approach is to first shape the organization to fit the design you want. This is called the ‘inverse Conway maneuver,’ and it became widely discussed in the software industry in the 2010s.
For example, if you want to split a service into small independent units, you set up a separate small team responsible for each unit from start to finish. The story that Amazon emphasized teams small enough to be fed with two pizzas also connects with this idea.
However, changing the organization does not automatically solve every problem. Splitting teams too finely can actually increase the coordination needed between them, so it is necessary to keep reviewing the structure of the system and the structure of the people side by side.
Conway's law reminds us that behind what look like technical problems lie human problems. If you want to build a good system, you should look not only at the code but first at how the people who write that code talk to one another.
Looking first at how we work together: that is the first step toward building better systems.
