Systems copy conversations: what Conway’s Law means when you hire a software house

Conway’s Law is about communication, not org charts. When you hire a software house, client and vendor form a temporary organization, and its channels end up in your system. What the research says, and four questions to ask before the first diagram.

Published
Series
Architecture starts with people, part 1
Reading time
8 min

Most people in IT know the short version of Conway’s Law: you ship your org chart. It is a useful slogan, and it sends you looking in the wrong place. The org chart shows who reports to whom. The system follows something else: who actually talks to whom while it is being designed.

For a company buying software, that difference matters more than it seems. When you hire a software house, the organization that designs your system is a new, temporary one, made of your company and the vendor together, and its communication channels will end up in the system whether anyone designed them or not.

This article looks at what Conway actually wrote, what research says about it, and what it means for someone choosing a vendor.

What Conway actually wrote

Mel Conway first sent his paper “How Do Committees Invent?” to the Harvard Business Review in 1967. It was rejected because, as Conway recalls, he had not proved his thesis. Datamation published it in April 1968 (Conway, Conway’s Law). The thesis is that organizations which design systems “are constrained to produce designs which are copies of the communication structures of these organizations” (Conway, 1968).

The name came later. Fred Brooks cited the paper in The Mythical Man-Month (1975) and called the idea “Conway’s Law” (Conway, Conway’s Law; Fowler, 2022).

Three points from the original paper are worth remembering, because they go further than the slogan:

  • The key word is communication. The structure that gets copied is how people exchange information, formally and informally. Martin Fowler, quoting Chris Ford, sums up the modern reading the same way: software coupling is enabled and encouraged by human communication (Fowler, 2022).
  • Organizing the team is already a design decision. Conway writes that the very act of organizing a design team means certain design decisions have already been made. Ford, Parsons, Kua and Sadalage put it in practical terms: every time work is delegated and someone’s scope is narrowed, the set of design alternatives that can be pursued narrows too (Building Evolutionary Architectures, 2nd ed., p. 196).
  • The first design tends to freeze. Conway notes that an organization without fully flexible communication will stamp an image of itself on every design it produces, and that abandoning a creation is painful and expensive. His conclusion is that flexibility of organization is important to effective design (Conway, 1968).

Conway’s examples also cross company boundaries. He describes two military services ordered to build a common weapon system, a contract research organization that divided its people between two compilers, and a manager subcontracting a difficult design task to an outside firm. In each case the design followed the way people and work were divided.

A simple illustration of the mechanism. If the legal department explains a requirement to the project manager, the project manager passes it to an analyst, and the analyst passes it to a developer, and that is the only path, the system will very likely reflect that chain, including whatever got lost at each step.

Is it actually a law? What research says

HBR rejected the paper for lack of proof. Since then the idea has been tested many times, in management research usually under the name “mirroring hypothesis”.

  • Organization shapes modularity. MacCormack, Rusnak and Baldwin compared pairs of software products with the same function: one built by a tightly coupled commercial firm, the other by a loosely coupled open source community. In every pair, the product of the loosely coupled organization was significantly more modular (MacCormack, Rusnak and Baldwin, 2012; working paper abstract: HBS 08-039).
  • Organization predicts defects. A Microsoft Research team built metrics of organizational complexity for Windows Vista. These organizational metrics were statistically significant predictors of failure-prone binaries and did better than traditional measures such as code churn, complexity, coverage, dependencies and pre-release bugs (Nagappan, Murphy and Basili, 2008). It is one system in one company, so it shows the effect can be strong, not that it is universal.
  • Informal channels break first. Herbsleb and Grinter studied a geographically distributed project at Lucent and found that integration was the hardest part. Coordination problems got worse across sites, largely because informal communication channels broke down. They concluded that stable plans and specifications help only to a point, and that unpredictable parts of a project need channels developers can open themselves when needed (Herbsleb and Grinter, 1999).
  • Common, but not automatic. Colfer and Baldwin reviewed 142 empirical studies. Mirroring is common in industry and firm studies, but not universal. Firms can deliberately “break the mirror”, for example through modular internal partitions or relational contracts that span organizational boundaries. Studies of open collaborative projects, mostly software, did not support the hypothesis (Colfer and Baldwin, 2016).

The last point is the useful one for decision-makers. Conway’s Law describes a strong default. It holds when nobody does anything about it, and it can be managed when someone does.

Which organization are we talking about?

Here is the part I think is most often missed when a company buys software.

When people apply Conway’s Law, they usually look at one company: the client’s departments, or the vendor’s teams. In my experience the organization that designs the system is the whole group of people around building it: the business, the IT department, legal, analysts, architects, the vendor’s developers. When you hire a software house, client and vendor together form a new, temporary project organization. That is the organization Conway is talking about.

That organization has its own communication channels, and most of them are created by accident: who signed the contract, which department sponsors the project, who is invited to refinement, which product owner is available this month. The research above suggests what to expect. Herbsleb and Grinter saw informal channels break between sites of one company. A company boundary is at least as strong a barrier (that is my reading, the study itself was about distributed sites). Colfer and Baldwin, on the other hand, show that relationships across organizational boundaries can be designed on purpose.

What AI will not do for you

It is tempting to hand this analysis to AI. In my experience it helps with processing material, for example notes and recordings from workshops with many stakeholders, but it is useless at the part that matters here. Identifying the communication channels Conway talks about is still work for people. You have to notice that a department exists, that it has its own tools and its own way of calculating the same thing, and that nobody invited it. No model will tell you about a conversation that never happened.

Designing the channels on purpose

If the communication structure shapes the system, the obvious move is to shape the communication structure first. In 2014 the ThoughtWorks Technology Radar put this on its “Trial” ring as the Inverse Conway Maneuver: evolving your team and organizational structure to promote the architecture you want (ThoughtWorks, 2014). Fowler credits the term to Jonny LeRoy and Matt Simons and recommends Team Topologies by Matthew Skelton and Manuel Pais (IT Revolution, 2019) as further reading on organizing IT teams this way (Fowler, 2022; Team Topologies).

Most of this literature is written for a company designing its own teams. In a client and vendor setup, you design something smaller and more fragile: the channels of a temporary organization. In my practice that comes down to four questions I want answered before the first architecture diagram:

  1. Who holds the domain knowledge? Including knowledge that lives in other departments’ own tools and spreadsheets.
  2. Who makes decisions? Which person or body can say “this is the correct way to calculate it” when two departments disagree.
  3. How do we resolve conflicts between departments? Better to agree on it at the start than to discover it during an escalation.
  4. Who can talk directly with the team building the solution? Every intermediary is a place where the system can drift away from reality, which is what Herbsleb and Grinter saw when informal channels broke down.

None of these questions needs a technical background. A CTO, an owner or a department director can ask them in the first meeting.

How to recognize a good vendor

For a buyer this leads to a practical conclusion. When you choose a technology partner, you choose more than a team that writes code. You choose half of the organization that will design your system.

A stack, the number of developers and impressive case studies tell you about a vendor’s capacity. A good vendor can also be recognized by wanting to understand your decision structure and your organization, and by being able to work directly with the business and domain experts. That is what lets it take responsibility for the business outcome, instead of only for closing the ticket.

You can often see this already in the sales process, in the questions a vendor asks. Does it ask who else in your company will use the system, or who already calculates the same thing in another tool? Does it ask who decides when departments disagree? Or does the conversation stay on features, rates and team size?

Even the best architecture drawn on slides will not hold if the organization does not have the communication paths needed to build it and later develop it. The next articles in this series go deeper into how to get to know that organization and how to map who needs to be informed, consulted and involved in decisions.

Sources

Choosing a vendor or shaping a project team?

Tell me what you are deciding and who is involved. I will tell you honestly whether I can help.

Work with meAll writing