Conway’s Law: When the Org Chart Writes the Requirements

By Sergey Nosov

14 October 2026

In April 1968, Melvin Conway told the story of a weapon system in two sentences. “Two military services were directed by their Commander-in-Chief to develop a common weapon system to meet their respective needs. After great effort they produced a copy of their organization chart.” A figure in his paper shows the result: one part for common logistics and one part special to each service.

Martin Fowler’s summary of the law that grew from that paper is about the people who build software. Conway’s Law, he writes, is “essentially the observation that the architectures of software systems look remarkably similar to the organization of the development team that built it.” In Conway’s example, though, the chart in the design belonged to the services that needed the weapon. They were its customers as well as its designers.

The organization you build for shapes the system too. Much software serves an organization with departments that each submit requirements, approval chains, budget holders, and, sooner or later, a reorganization. The engineers who build the system rarely get to redraw that organization’s chart. They can still learn to see the chart in the requirements, add the conversations it lacks, and keep it from hardening into the design.

What Conway Actually Wrote

Conway submitted “How Do Committees Invent?” to the Harvard Business Review in 1967. HBR, he recalls on his website, “rejected it on the grounds that I had not proved my thesis.” Datamation published it in April 1968. Fred Brooks quoted its thesis in The Mythical Man-Month in 1975 and called it Conway’s Law. As Conway puts it, “The name stuck.”

The paper asks a precise question: “Is there any predictable relationship between the graph structure of a design organization and the graph structure of the system it designs?” Conway answers, “Yes, the relationship is so simple that in some cases it is an identity.” The argument is short. Draw the system as a graph, with subsystems as nodes and interfaces as lines, and find the group that designed each subsystem. Two subsystems can communicate only if the groups that designed them negotiated an interface. So where two groups never talked, their parts do not connect.

One of his examples is small enough to remember: “A contract research organization had eight people who were to produce a COBOL and an ALGOL compiler. After some initial estimates of difficulty and time, five people were assigned to the COBOL job and three to the ALGOL job. The resulting COBOL compiler ran in five phases, the ALGOL compiler ran in three.”

Conway stated the thesis in the third paragraph from the end. Organizations “which design systems (in the broad sense used here),” he wrote, “are constrained to produce designs which are copies of the communication structures of these organizations.” His website offers a shorter version as “one form of the paper’s thesis.” It is the version Fowler quotes: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

Two details in the paper matter for everything that follows. The first is scope. Conway defines design as the “intellectual activity which creates a useful whole from its diverse parts.” His examples include “the creation of specifications for a major weapon system, the formation of a recommendation to meet a social challenge, or the programming of a computer.” A design, he adds, is usually produced for a sponsor, and the design organization “may or may not be involved in the construction of the system it designs.” By that definition, writing requirements is design.

The second detail is that the law follows communication, not the org chart. The chart matters only as far as it controls who talks to whom. Conway wrote: “To the extent that organizational protocol restricts communication along lines of command, the communication structure of an organization will resemble its administrative structure. This is one reason why military-style organizations design systems which look like their organization charts.”

Some restriction is unavoidable. Conway notes that the possible communication paths in a group grow roughly as half the square of its size. Even a moderately small organization, he adds, must restrict communication so that people can get work done. My article on combinatorics in software engineering works through that count.

The Organization You Build For

If you work for an agency or a consultancy, the organization you build for is a client. If you work on an in-house team, it is your own company’s business units. Either way, the people who decide what the system must do are often not the people who build it, and their requirements arrive already divided.

Two of Conway’s observations, applied to requirements, explain why that division matters. “The very act of organizing a design team means that certain design decisions have already been made,” he wrote. He also observed that “every time a delegation is made and somebody’s scope of inquiry is narrowed, the class of design alternatives which can be effectively pursued is also narrowed.” When each department writes its own requirements, that narrowing happens before an engineer is in the room. Where requirement changes go up and down each department’s chain of command, Conway’s point about protocol applies: the communication structure resembles the chart.

Take a hypothetical company with three departments. Sales wants to track accounts and deals. Operations wants to manage fulfillment. Finance wants invoices and reports. Each department submits its own requirements. Suppose those requirements become three modules whose interfaces copy how the departments get along. Sales and Finance meet every week and agree on the data they share, so their modules exchange it smoothly. Operations and Finance rarely coordinate, so the handoff between their modules is clumsy: a nightly export, a spreadsheet, a reconciliation report that nobody owns.

So ask of any structure like this: did we choose it because it was the best design, or did it emerge from how the people who asked for it are organized?

Three Tensions

Siloed Requirements

Departments often submit requirements with little awareness of what the others have asked for. The result can be duplicated logic, contradictory business rules, and data models that do not line up. Engineers receive fragments of a picture and are expected to assemble a coherent whole, but if the people who wrote the fragments never talked, coherence is hard to reach. One signal stands out: the same concept built two ways in one system, such as two definitions of a customer or two shapes of an order. It may be Conway’s Law at work, but it is not automatically a defect.

Eric Evans’s Domain-Driven Design Reference lists several reasons a large project ends up with multiple models, and two of them matter here. “Two subsystems commonly serve very different user communities, with different jobs, where different models may be useful. Teams working independently may solve the same problem in different ways through lack of communication.” The first is a legitimate boundary between user communities. The second is a communication gap copied into the code.

To tell the two apart, ask what should happen when a value changes. Suppose Sales calls a customer an account it sells to, and Finance calls a customer the party it bills. When both records describe the same legal party and its name changes in Sales, the next invoice should carry the new name. If it does not, that is a defect: one fact in two places that nobody keeps in step. Agree who owns that fact and how its changes reach the other side.

A deal stage in Sales and a credit limit in Finance are different: neither needs to follow the other. When a field fits neither case, such as an address, take the question to both departments. And if one account can have several bill-to parties, the departments are describing two concepts that share a name. Often you find both: a few shared facts inside two different concepts. Give the concepts different names, such as account and bill-to party, or keep each meaning inside its own explicit context, and translate at the boundary.

Fowler sees the same trouble with words like customer and product again and again. He quotes Evans’s warning that “total unification of the domain model for a large system will not be feasible or cost-effective.” The goal is not one customer record for the whole company. It is to know which kind of duplicate you have.

Politics That Become Constraints

When two departments do not collaborate, whether because of rivalry, history, or leaders who do not talk, their parts of the system often cannot share data cleanly either. Approval hierarchies can create rigid module boundaries that resist refactoring. Evans makes a related point about two development teams in his customer/supplier pattern: the dependent team’s problems “are not improved by cumbersome change request procedures with complex approval processes.” And a powerful stakeholder may insist on a dedicated subsystem that the domain does not need.

Conway saw a similar motive in the managers of design efforts. “As long as the manager’s prestige and power are tied to the size of his budget, he will be motivated to expand his organization.” In a note, he offered one reading of his argument: “one design group almost never will compromise its own design to meet the needs of another group unless absolutely imperative.”

The most difficult integration problems are often organizational problems in disguise. Evans observes that the constraints one part of a system places on another “manifest themselves primarily through non-technical channels that are sometimes hard to relate to the design decisions they are affecting.” When you hit a wall trying to unify two parts of a system, ask whether the real wall stands between two departments rather than two codebases. If it does, refactoring alone will not remove it.

Plan for what the other side will actually do, not for what it promises. Evans writes about development teams, but his warning fits any group that owns a system you depend on and has no reason to meet your needs. “Altruism may motivate upstream developers to make promises, but they are unlikely to be fulfilled.” His answers for that case are to conform to the other side’s model or to translate at the boundary.

Reorganizations That Rewrite the Scope

Organizations merge departments, replace leaders, acquire companies, and sell business units, and the requirements can shift to match, sometimes overnight. Features that were separate may have to merge, and features that were one may have to split. Software keeps archaeological layers of past reorganizations. If a codebase seems structured for no good reason, it may have made sense under a previous org chart.

Conway and Brooks saw the same coupling from the designers’ side. Conway’s conclusion warns: “Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change.” Brooks, summarizing Conway, drew the consequence: “If the system design is to be free to change, the organization must be prepared to change.” When the organization you build for reorganizes, the pressure comes from the other end. The chart changes first, and the system has to follow wherever responsibilities, rules, or workflows changed with it.

How Strong Is the Mirror?

HBR wanted proof. Conway had an argument, and researchers have since gathered evidence. Alan MacCormack, Carliss Baldwin, and John Rusnak compared pairs of software products with the same function, one built by a commercial firm and one by an open-source community. Their 2012 paper reports that in every pair, “the product developed by the loosely coupled organization is significantly more modular than the product from the tightly coupled organization.” The differences reached “up to a factor of six” in how far a change in one component could spread to others.

In 2016, Lyra Colfer and Carliss Baldwin reviewed 142 empirical studies of what they call the mirroring hypothesis. Of the 50 descriptive studies involving firms, 70 percent found strong evidence of mirroring, 22 percent partial support, and only 8 percent none. Within firms and between buyers and suppliers, about a quarter found partial or no mirroring. In the buyer–supplier studies, mirroring meant that firms tended to buy the more modular components. Open collaborative projects, most of them software, were the exception: 56 percent of their descriptive studies found no mirroring. The authors argue that digital technologies make new modes of coordination possible.

Two limits apply. The mirroring hypothesis, Colfer and Baldwin note, “predicts correspondence but does not impose a direction of causality.” And neither paper tests whether the departments that write requirements shape what another group builds. That step is mine. It rests on Conway’s definition of design, not on their findings.

The review found that firms can break the mirror with modular partitions inside their boundaries or relational contracts across them. A relational contract is a long-term relationship that both firms value enough to keep cooperating. Such contracts “become more robust through repeated positive interactions, relationship-specific investments, and shared understanding of the evolving technical system.” Other firms practice partial mirroring: they invest in knowing more of the system than the part they build. Relational contracts and partial mirroring both add communication and shared knowledge across a boundary, which fits Conway’s thesis rather than defeating it.

Modular partitions work against the thesis. Modular architectures, the authors note, do not emerge on their own inside firms, and the firms that built them made modularity “a top priority.” Not every attempt succeeded: “nature sometimes stops the process by exposing unknown but critical interdependencies.” Dividing an organization too early fails the same way. In the ten studies where unmirrored firms did poorly, the common thread was “premature modularization”: the firms had divided the work before they understood the technical dependencies across the division.

So the two levers are not equal. Adding the conversations a design needs works with Conway’s Law. Drawing a boundary the organization would not draw works against it, and such a boundary holds only where you know what crosses it.

What You Can Do without Redrawing the Chart

Fowler lists three responses to Conway’s Law: ignore it, accept it, or apply the inverse Conway maneuver. He describes the last as “change the communication patterns of the designers to encourage the desired software architecture.” He credits the term to Jonny LeRoy and Matt Simons, writing in December 2010. On organization design, he recommends Team Topologies by Matthew Skelton and Manuel Pais, now in a second edition. My Software Development Principles series has entries on Conway’s Law and on the reverse Conway maneuver, as the series calls it.

All three responses concern the designers, the people whose communication the system copies. The organization you build for is different: its departments and reporting lines are not yours to change. What you can change is smaller: what you know, which groups talk to each other about the system, and where your system draws its boundaries. That is enough for three moves. Together, they add the communication paths the design needs and keep the system from depending on paths that do not exist.

Map the Organization before the Architecture

Before you draw a component diagram, learn which departments or people own which requirements. Record who actually talks to whom, not only who reports to whom, and who must approve a change. Look for gaps: places where two groups should collaborate on a shared workflow but do not. The map shows where coordination will be hard, and tracing each shared workflow shows what has to cross. For the hypothetical company, one entry might read:

Concept: order
  Operations: a job to fulfill
    owner: fulfillment
  Finance: something to invoice
    owner: billing
  Possibly shared: order number,
    items, ship date
  Meanings and owners: not agreed
  Talk to each other: rarely
  Who approves changes:
    both department heads
  Risk: the handoff between
    fulfillment and invoicing

This is Evans’s context map, extended to the people who write the requirements, and his advice for drawing one applies: “Map the existing terrain. Take up transformations later.”

The map also lets you plan around a seam before you hit it. Fowler tells of a technical leader who had just been made the architect of a project with six teams in different cities. “I made my first architectural decision,” the leader told him. “There are going to be six major subsystems. I have no idea what they are going to be, but there are going to be six of them.”

A map of the organization you build for supports the same kind of decision. Where two departments rarely talk, do not plan on a seamless handoff between their parts. Find what their shared workflow still needs, make the interface explicit, keep it as narrow as the domain allows, and agree who settles the questions that cross it.

Bridge the Silos

The engineers who build a system often see more of the process than any single department does. Use that view. When you spot duplicated or conflicting requirements, raise them early, because the people who wrote them may not know the conflict exists. Raising a conflict is not overstepping. It is part of delivering a system that works.

Do not quietly absorb contradictions into the code. Bring the stakeholders together and settle the question before you build. If you cannot reach them, take the conflict to whoever owns the requirements. If no one decides, state your assumption in writing and isolate the contested rule so that a later decision can change it.

Where the domain supports a shared model or a unified workflow, propose one, even if the org chart does not. Explain to each group how its decisions affect another group’s part of the system. Bridging of this kind is a small version of the inverse Conway maneuver, one that needs no reorganization, because it adds the communication paths the design needs.

Bridging does not mean merging everything. Where two sets of functionality have “no significant relationship,” Evans’s Separate Ways pattern cuts them loose entirely, because “integration is always expensive, and sometimes the benefit is small.” Short of that, suppose two departments mean different things by a word and exchange little. Two models with one well-defined handoff may serve them better than a shared model that neither owns.

Design for Change

Assume the organization you build for will reorganize. If the architecture is coupled to today’s org chart, a reorganization can become a rewrite. Favor loose coupling and clear interfaces between modules, because the chart will shift and the software has to survive it. Draw boundaries after the map, once you know what crosses them, and name them after business capabilities, not departments.

Chris Richardson defines a business capability as something a business does to create value. His pattern catalog lists “stable architecture since the business capabilities are relatively stable” among the benefits of decomposing a system around them. He notes that departments are a fair place to start looking for capabilities. But department names are what reorganizations change. Suppose billing moves from Finance to a new shared-services group. A module called invoicing still says what it does. A module called finance now misleads everyone who reads it.

Where your system depends on one that another department controls and changes on its own schedule, put a translation layer between them. Evans calls it an anticorruption layer: an isolating layer that translates the other system’s functionality into your own domain model. When the other department’s system changes, the layer can absorb changes in representation. Changes to business rules or required behavior may still reach your model.

Brooks named the asymmetry that makes this the engineer’s lever: “Structuring an organization for change is much harder than designing a system for change.” Engineers rarely control the first. They have far more say over the second. Before you commit to a structure, ask: if the organization you build for reorganizes next year, how much of this architecture survives?

Checklist

Recognize the pattern. When something in the architecture feels awkward—a painful integration, a confusing API, duplicated logic—ask whether it reflects a technical need or an organizational one.
Map the organization you build for. Record who owns each requirement, who actually talks to whom, and who must approve a change.
Sort every duplicate. For each concept that two groups define, find the facts kept in two places, and agree who owns each and how its changes reach the other side. Give the rest two names or two explicit contexts, and translate between them.
Surface conflicts early. Do not quietly absorb contradictory requirements. Bring the stakeholders together before you build, or take the conflict to whoever owns the requirements.
Plan for what the other side will do. Where a group has no reason to meet your needs, conform to its model or translate at the boundary, and do not build on promises.
Build for the next reorganization. Name modules after capabilities, draw boundaries after the map, and ask how much of the architecture would survive a new org chart.