Ideas How systems shape choices

Organisations Ship Their Own Shape

The structure of a system tends to copy the communication structure of the organisation that built it, so choosing how to organise people is also choosing what the product will look like.

The idea in plain words

Give three teams a compiler to build and you will get a three-pass compiler. That old joke is a version of Conway’s law: a system tends to mirror the structure of the organisation that designs it. Where two teams must coordinate, there will be an interface. Where one team owns everything, the parts will be tightly entangled. Where teams barely talk, the product will have gaps that customers fall into.

The law is usually cited as a curiosity of software. It is better understood as a statement about decisions. Every choice about how to divide people into groups is also a choice about how the product will be divided. Org design is product design by other means.

Where it comes from

Melvin Conway, a computer scientist, submitted a paper to the Harvard Business Review in 1967; it was rejected, and published in Datamation in April 1968 under the title “How Do Committees Invent?” Its thesis was that organisations which design systems are constrained to produce designs which are copies of their own communication structures. Conway reasoned that designing a system means dividing it into parts and assigning parts to people; the people who build connected parts must communicate; so the communication paths of the organisation become the interfaces of the system.

Frederick Brooks cited the idea in The Mythical Man-Month (1975) and called it Conway’s law, which is how it became famous. Brooks’s own experience managing IBM’s System/360 operating system gave the idea weight: adding people to a project multiplies the communication paths between them, and the system’s structure reflects the strain.

For decades the law was supported mostly by anecdote. In 2012 Alan MacCormack, John Rusnak and Carliss Baldwin tested it by comparing the architecture of software products built by tightly coupled commercial teams with matched products built by loosely coupled open-source communities. The commercial products were consistently more tightly coupled internally. Lyra Colfer and Baldwin later reviewed many studies under the name mirroring hypothesis and found broad support, with important exceptions where organisations deliberately broke the mirror.

The engineering principle that complements Conway’s law is David Parnas’s 1972 idea of information hiding: divide a system so that each module hides a design decision likely to change. Parnas’s modules and Conway’s teams are two views of the same problem.

What it does to the mind

Conway’s law operates mostly below awareness. Teams experience their boundaries as natural, and design within them. Engineers on one team rarely see that the confusing part of the product sits exactly where their team meets another; to them, it is the other team’s problem. Customers see the seams more clearly than anyone inside.

It also explains why reorganisations are so disruptive. A new structure demands new interfaces, which take time to form, and the product drifts towards the new shape slowly, carrying traces of the old one for years.

Where it shows up

The operating systems essay and the web frameworks essay both describe architectures shaped by who built them and how they worked together. Steve Yegge’s Platforms Rant describes Amazon’s mandate that teams communicate only through service interfaces, a deliberate use of Conway’s law to produce a platform. Nadella’s “Bold Ambition” memo set out to change Microsoft’s culture alongside its strategy, partly because the old divisions shaped the old products. The OS/2 road shows two companies, with very different cultures, jointly building one operating system.

What it asks of someone deciding

Design teams and architecture together. If you want a modular product, create teams that own modules end to end and communicate through clear interfaces. If you want a seamless experience, someone must own the seams.

Read your product for the org chart. Where users get confused, look for a boundary between teams.

Use the law in reverse. Some companies deliberately reorganise around the architecture they want, sometimes called the inverse Conway manoeuvre. It works, but slowly, and the transition is where products suffer most.

Argue with it

The strongest objection

The relationship runs both ways and is not destiny. Good architects can design systems that cut across team boundaries, and some organisations deliberately change their structure to fit a desired architecture, which suggests the law describes a tendency to be managed, not a fate.

Take it to your team

Questions to ask

  • Which seams in our product are really seams between teams?
  • What would a customer have to understand about our organisation to use our product?
  • If we want a different architecture, which team boundaries would we have to move first?

Follow the thread

Connections

Read further

Bibliography

  1. Melvin E. Conway, “How Do Committees Invent?” Datamation 14, no. 4 (April 1968), 28–31.
  2. Frederick P. Brooks Jr., The Mythical Man-Month (Addison-Wesley, 1975).
  3. Alan MacCormack, John Rusnak and Carliss Y. Baldwin, “Exploring the Duality between Product and Organizational Architectures,” Research Policy 41, no. 8 (2012), 1309–1324.
  4. Lyra J. Colfer and Carliss Y. Baldwin, “The Mirroring Hypothesis,” Industrial and Corporate Change 25, no. 5 (2016), 709–738.
  5. David L. Parnas, “On the Criteria to Be Used in Decomposing Systems into Modules,” Communications of the ACM 15, no. 12 (1972), 1053–1058.

How to cite

Shrikant Kumar. “Organisations Ship Their Own Shape.” Idea, Telos. https://shrikantk.com/ideas/conways-law/

↑ ↓ to move↵ to open⌘K to toggle