Picture a staffing sheet at a small contract research organization. It has eight people and two jobs: a compiler for COBOL and a compiler for ALGOL. After some rough estimates of how hard each will be, a manager writes five names under COBOL and three under ALGOL. Both compilers get built. The COBOL compiler runs in five phases. The ALGOL compiler runs in three.
Melvin Conway told that story in the April 1968 issue of Datamation, in four pages titled "How Do Committees Invent?"1 It is an anecdote, not a study, and nobody can rerun it. But it shows two things that look as if they belong to different people. One is the system's structure: how the parts are divided, and which part depends on which. That is the architect's drawing. The other is the organization's communication structure: who works with whom, who has to ask whom before changing something, and which conversations happen without a meeting. That is the executive's drawing, and it usually looks like an org chart.
My argument is that inside a firm these are one decision. Teams tend to build systems whose seams fall along their own lines of communication, so whoever redraws the reporting lines is also redrawing the system, whether or not an architect is in the room. That is not a law of nature, and this essay does not claim it is. Open collaborative projects often escape it, and firms that set out to escape it can, at a cost they have to budget. The claim is about the default: what you get when nobody decides otherwise.
Four pages in 1968
Conway's argument begins before anyone writes a line of code. To design a system, someone first has to organize the people who will design it, and that act already settles part of the design, whether anyone intends it or not. A team that has been divided into groups will divide the problem among the groups, and each group will build its piece and negotiate the boundaries with its neighbors. Where two groups never need to talk, their pieces never need to connect. Conway put it in the language of graphs: a system and the organization that designed it are each a set of nodes joined by lines, and the lines of the first map onto the lines of the second. His thesis, on the article's last page, is that organizations which design systems are constrained to produce copies of their own communication structures.
He offered a second story, sharper than the first. Two military services were told to develop a common weapon system that met both of their needs. After great effort, Conway wrote, "they produced a copy of their organization chart."
The mechanism he proposed is arithmetic. The number of possible communication paths in an organization, he noted, is roughly half the square of the number of people in it. By that rule of thumb, eight people have about 32 possible paths (the exact count of pairs is 28), and fifty people have more than 1,200. No organization of fifty lets everyone talk to everyone about everything. It restricts communication by giving people managers, teams and channels, and each restriction is a place where two parts of the system will meet through an interface rather than through a conversation. The larger the organization, Conway argued, the less flexible its communication, and the more pronounced the copying.
The popular one-sentence version of Conway's law, the one quoted in slide decks, is a later paraphrase rather than the 1968 text. The original is more careful and more useful. It ends with advice: a design effort should be organized according to the need for communication, and the organization has to stay flexible enough to change as the design does. It also contains the warning I find most often forgotten. The greatest single cause of poorly designed systems, Conway suggested, had been a design organization in need of work. In my reading, that is a team that existed before the problem did and shaped the problem to fit itself.
Matched pairs
For forty years the idea was mostly argued, not measured. One of the cleanest tests came in 2012, when Alan MacCormack, Carliss Baldwin and John Rusnak published a study in Research Policy that compared software products built for the same purpose by very different organizations.2 In each pair, one product came from a loosely-coupled organization, mostly distributed open-source contributors, and the other from a tightly-coupled one, a commercial team working closely together. The pairs covered financial management, word processing, spreadsheets, operating systems and databases.
Their measure of structure was propagation cost. Take every source file in a product and trace the other files it could affect, directly or through a chain of dependencies; propagation cost is the average share of the system that a change to one file could reach. A low number means changes stay local. A high number means a change anywhere can ripple almost everywhere.
In every pair they examined, the product of the loosely-coupled organization was significantly more modular. The gaps were large, up to a factor of six. In the financial management pair, a change to the average file could reach 7.7 percent of the open-source product and 47.1 percent of the commercial one. Linux and Solaris, two operating systems that both descend from Unix, came out at about 7 percent and 23 percent; for Solaris, the authors note, that means a change to a source file could potentially affect more than 2,400 other files.
Why would organization show up in code this way? The authors offer two explanations and decline to choose between them. In one, the design drifts toward its environment: people who sit together solve problems by talking, so connections between their parts form easily and nobody notices them accumulating, while people spread across the world can only coordinate through the code, so they keep the parts apart. In the other, the difference is deliberate: an open-source project has to be modular to attract contributors who will each understand only a piece of it. They think both mechanisms are probably at work. Either way, the structure of the code tracks the structure of the conversation.
The study has limits the authors state plainly. It has five matched pairs (six comparisons, since one pair is run twice). The products were not built at the same time, and the authors did not test directly whether each pair was functionally equivalent. It is about software. But the direction never flipped.
The org chart as a predictor
If organization shapes structure, it should also predict where structure fails. In 2008, Nachiappan Nagappan, Brendan Murphy and Victor Basili tested that on Windows Vista: 3,404 binaries and more than 50 million lines of code.3 For each binary they computed eight organizational measures: how many engineers had edited it, how many of those engineers had since left, how often it was edited, how much of it its main owning group controlled, and how far apart in the reporting structure its contributors sat. Then they asked which binaries those measures would flag as likely to fail.
The organizational model did better than every model built from the code itself. Of the binaries it flagged as failure-prone, 86.2 percent were (its precision), and it found 84.0 percent of the failure-prone binaries (its recall). Models built from code churn, code complexity, test coverage, dependencies and pre-release bug counts all scored lower; the closest on precision, test coverage, found barely half of the failure-prone binaries. Who touched the code, and how far apart they sat, said more about where it would break than the code did.
Two cautions. This is one system, and the authors say themselves that results from one environment cannot be assumed to hold elsewhere. And it measures ownership and organizational distance, not conversation itself. It shows that the org chart carries information about the code. It does not show the conversations.
Coordination that matches the work
The same year, Marcelo Cataldo, James Herbsleb and Kathleen Carley came closer to measuring the conversations.4 They studied 39 months of development on one company's main product, a large distributed system built by 114 developers in eight teams across three locations, and 2,375 modification requests that needed more than one team. For each piece of work they asked two questions. Given which files depended on which, who needed to coordinate with whom? And who actually did? They called the match between the two socio-technical congruence.
When developers' coordination matched what the dependencies required, modification requests were resolved faster: on average 32 percent faster, taking all four of their congruence measures together. A second finding is easy to miss and more practical. The dependencies that mattered most were not the ones an architecture diagram shows, where one module calls another or reads its data. They were what the authors call logical dependencies: files that tend to change together in the same piece of work. The org chart and the call graph can agree perfectly while the work that actually changes together crosses a team line every week.
This is also one system, with particular technical properties, as the authors note. But it turns Conway's idea into something a manager can act on: map which parts change together, and check whether the people who change them talk.
Where the mirror breaks
The broadest test is a review. In 2016, Lyra Colfer and Carliss Baldwin examined 142 empirical studies of what they call the mirroring hypothesis, the prediction that organizational ties will correspond to technical dependencies.5 They sorted them by setting. In studies of industries and firms, mirroring was common but not universal: of the descriptive studies, 70 percent found strong evidence of it, 22 percent partial support and 8 percent none. In open collaborative projects, most of them software, the picture reversed: 56 percent of the descriptive studies did not support the hypothesis.
The exception is instructive. Mirroring, in their account, is economical: aligning who talks with what depends on what is a cheap way to manage a complex system with limited attention. Digital technology, they write, has sharply reduced both design and communication costs, which are the core of that economy. A contributor who can read the whole codebase, see every change and ask a question in public does not need the org chart to tell them where the interfaces are.
Firms can break the mirror too, on purpose. Colfer and Baldwin describe Black and Decker building a modular platform for its power tools through intense collaboration across functions, Sony designing the Walkman as a reconfigurable platform, and a team at Netscape redesigning the Mozilla codebase for modularity after open-source developers rejected it as too complex. In each case, they note, the engineers made modularity a top priority and "worked against their own organizational tendencies." That is the important part. The escape was a project with a goal and an owner. It did not happen by default.
They add a warning for anyone tempted to mirror perfectly. A firm whose organization fits today's architecture exactly can be blindsided when the architecture changes from outside, because nobody inside was placed to see across the lines. They call this the mirroring trap. Their remedy is partial mirroring: draw knowledge boundaries wider than task boundaries, so teams understand more of the system than they are responsible for.
A reorganization is a design review
Put the evidence together and the practical claim is modest. Inside a firm, the lines of communication are a strong prior on the lines in the system. Draw a new reporting line between two teams and you have made it a little more expensive for their parts of the system to depend on each other, and a little more likely that the parts will drift apart, or that the dependencies will stay and the coordination will not. Neither outcome shows up in the reorganization memo.
Take an illustrative case. A company splits one platform team into two, one for customer-facing services and one for internal data, so that each has a clearer mandate. On the org chart this is a clean line. On the dependency map, the order service and the reporting service change together every time the product team adds a field, and they now sit on opposite sides of it. The day after the reorganization nothing has changed. A year later the field arrives in the reports a release late, a translation layer has grown between the two services, and two managers are negotiating a backlog that used to be one conversation. Nobody chose that architecture. It was chosen when the line was drawn.
The remedy is not to stop reorganizing. It is to make the second decision visible when the first one is made. Lay the org chart and the dependency map on the same table, mark every dependency the new lines will cut, and for each one decide: move the line, move the dependency, or name the people who will keep talking across it, and how often. No. 27, "The invoice does not draw the boundary.", made the same point about lines drawn by a contract with an outside supplier. The lines drawn inside the firm are drawn more casually, and they last as long.
Objections, considered
Open source disproves it. This is the strongest objection, and the review supports it: most descriptive studies of open collaborative projects do not find mirroring. I concede it, and narrow the claim to firms, where the pattern is strong. But look at what open projects use instead of an org chart: code anyone can read, changes everyone can see, and work divided into pieces small enough to do without a meeting. Those are things a firm can adopt on purpose. The objection does not make the effect disappear. It shows what escaping it costs.
It is correlation, or the arrow runs the other way. MacCormack and his coauthors offer two rival mechanisms, and Colfer and Baldwin stress that the hypothesis predicts correspondence without fixing a direction of cause. The argument survives either direction. If structure shapes design, a reorganization reshapes the system. If design shapes structure, the existing architecture limits which reorganizations will work. Either way the two decisions belong at the same table.
Good engineers design to the problem, not to the org chart. Some do, and the review names them. But it also says how: they made it a top priority and worked against their own organization's grain. Breaking the mirror is possible. It is a funded project with an owner, which is an argument for deciding it explicitly, not for assuming it will happen.
The studies are small, old and about software. All true. Five matched pairs, one Windows release, one company's product. That is why the claim here is "tends to", never "always", and why the 142-study review carries the most weight. Each study is narrow; together they point the same way.
Every line drawn between two teams is a line someone will later find between two parts of the system.
Before the next reorganization
- Which dependencies does the new chart cut? Put the org chart and the dependency map side by side, and mark every place a team line crosses work that changes together.
- For each cut, who will talk to whom, and how often? If the answer is nobody, expect the system to drift toward the new lines.
- Does any component now belong to two teams? Several components per team is ordinary. One component split across teams is a design decision, so write it down.
- Is this team shaped by the problem, or is the problem being shaped to fit the team? Conway's question, from 1968, about a design organization in need of work.
Back to the staffing sheet. Nobody in that contract research organization decided that the COBOL compiler should have five phases. Someone decided that five people would build it, and the people did what people do: each took a piece, and the pieces met where the people met. The next time an org chart is approved, it is worth remembering that a system is being approved with it, and asking whether anyone has looked at that drawing too.