Your Org Chart Draws Your Product's Architecture

In 1968 Melvin Conway noticed something about compilers. A company put five people on a COBOL compiler and three on an ALGOL compiler. The COBOL compiler had five phases. The ALGOL compiler had three.

Nobody designed it that way. The way the people were divided decided the structure of the software.

Conway turned this into the rule that now carries his name: organizations that design systems produce designs that copy their own communication structures. Where two teams have to agree, an interface appears. Where they never talk, no interface appears, or a bad one does.

From there it is a short step to a popular claim: software product architecture is the same art as organization design. As a description of the kind of thinking involved, it holds. As a claim that the two are the same art, it fails, and the places where it fails are where the most expensive mistakes in organization design get made.

The same kind of problem

Both disciplines divide one system into parts. Both decide where the boundaries go, what crosses them, and how much coupling between the parts the whole can bear. Cohesion inside a part, dependencies between parts, interfaces, trade-offs with no single right answer, a design that decays when nobody tends it: the architect and the person designing an organization work with the same concepts.

Conway goes further. The two disciplines look alike because they describe one system from two sides. He called the relationship a homomorphism, a mapping that preserves structure, from the graph of the organization to the graph of the system. Change one and you change the other, whether you planned to or not.

Christopher Alexander said the same about buildings in 1977. In A Pattern Language (pattern 205) he argues that no building ever feels right to the people in it unless its physical spaces match its social spaces.

That far, the analogy holds.

The parts react

A module does not respond to being designed. People do. Change their boundaries and they route around them. Change their targets and they optimize for the targets. They learn, they negotiate, they leave.

Software architecture works on a system that is complicated: it can be taken apart, understood, and its behaviour predicted to a large degree. An organization is a complex system. The design changes the behaviour of the thing it describes, and what the design caused shows up only in operation.

An organization changes in steps

Code can be rewritten, tested and rolled back. A refactoring that did not work costs a few days. A reorganization spends trust, people's identities and their careers, and no commit brings any of that back. No test suite tells you before deployment whether the new structure works.

So an organization changes in small steps, watching what each step caused. Software can choose an evolutionary approach. An organization has no other option.

Teams need more paths to each other

In 1972 David Parnas stated the principle good modularity rests on: each module hides its decisions from the others (information hiding), and boundaries are drawn so that as little as possible crosses them. A change in one module should not spill into the rest. In software, that is right.

Carry the principle over to teams and you get component teams. Each team owns its part, the interfaces between teams are narrow and formal, and little communication crosses the boundaries, exactly as modularity wants. The customer, though, asks for a feature, and a feature crosses five components: five teams, five backlogs, five sets of priorities. Every such feature becomes a coordination project. Teams wait on each other, integration happens at the end, and nobody owns the outcome.

LeSS goes the opposite way on purpose. Feature teams work across the whole product, the code is shared, and teams refine the backlog together. The number of communication paths between teams goes up. An organization that has to adapt needs people who can reach agreement anywhere in the product, because it cannot know in advance where the next change will land.

Conway recommended the same at the end of his paper: structure the organization according to who needs to communicate with whom. When the goal is speed and adaptability, that need runs across components.

The architect's best habit, keeping communication across boundaries to a minimum, produces in an organization exactly the problem organization design exists to solve.

The organization shapes the architecture

Conway says the organization constrains the architecture. The phrase "the same art" invites reversing that direction: design the target architecture, then assemble the teams to match it. The move has a name, the Inverse Conway Maneuver, and the book Team Topologies spread it with the advice that teams should be designed to match the required software architecture.

In the same 1968 paper, Conway writes that the design which occurs first is almost never the best possible. Tie the teams firmly to the first architecture and you fix its mistakes into the org chart. Every later correction to the architecture then becomes a reorganization, and a reorganization has no revert.

An organization runs several graphs at once

Software has, in essence, one dependency structure. An organization has several at the same time: who reports to whom, who actually talks to whom, how the money flows, what gets rewarded, who holds which power. These graphs often disagree with each other.

Conway's Law follows the real communication. Real communication departs from the org chart wherever the other graphs pull it.

Two views of one system

A more accurate sentence would be this: software architecture and product organization design are two views of the same system. The same kind of problem, different materials. Your org chart is drawing your product's architecture.

You can check this against your own data. Adam Tornhill described the method in Your Code as a Crime Scene (2015): from version history, find which modules change together and, for each one, who changes it most. Then check whether those people have an easy path to each other. Where they do not, defects accumulate.

Try it on your product:

• Which modules change together even though different teams own them?
• Do the people who change them talk directly, or through a manager, another city, another backlog?
• Do defects pile up in exactly those places?

Where the code changes together and the people do not talk, your organization is designing your architecture right now. Nobody decided that.