Conway's law: draw the team before the product

The seams in a product sit on the seams in the org chart

Contents4

Systems copy communication structure
Running it backwards
Decisions for an engineering team in Japan
Where this sits in the method

Series「People Don't Follow the Org Chart」 · Part 5 of 13 · Part 2 · How structure shapes behavior
Prologue：The people who aren't on the org chart

Your product will end up shaped like your org chart, so draw the team you want before you build. Here is what happens otherwise. A company sets up two engineering teams in Japan, one for mobile and one for backend, reporting to two different leads. A year later the product has two login flows, two sets of error messages and two API documents that don't agree. Nobody decided this. The product just grew into the shape of the org chart.

Systems copy communication structure

In a 1968 paper Melvin Conway wrote the sentence that became Conway's law. An organization that designs a system will produce a design whose structure copies the organization's communication structure. His example was a compiler. Give it to three teams and you get a three-pass compiler.

There's nothing mysterious about why. Two modules need an interface, and the people on each side negotiate it. Teams that talk a lot produce fine-grained interfaces. Teams that rarely talk produce coarse ones, duplicated, each side doing its own thing. The seams in the product grow along the seams in the organization.

People mostly agree the law is true. They argue about how strong it is. Empirical studies in open source and enterprise software have found the correspondence. Others say it's a tendency, and that a good architect can deliberately cross organizational boundaries. I think the tendency is strong enough that if you don't design against it, it will do the designing for you.

Running it backwards

If the product is going to grow into the organization's shape, decide the product's shape first and draw the organization to match. This is called the Inverse Conway Maneuver.

Start by drawing the target product architecture. How many major modules, where the boundaries are, which boundaries need tight coupling and which can stay loose. Then draw teams to match. Each cluster of tightly coupled modules goes to one team, and team boundaries line up with module boundaries. Only then do you hire. Define roles from what each team is responsible for. Don't build teams out of whoever happens to be available in the market.

The seams in a product sit on the seams in the org chart

The two engineering teams the company in this article set up in Japan, plus the most common split, read through Conway’s law (1968)

A year laterTwo login flows, two sets of error messages, two API documents that don’t agree

Mobile and backend report to two different leads

Put a module cluster that needs tight integration in one location, under one reporting line

Common splitFront end in Tokyo, back end at HQ

A time zone and a language across the densest interface

Cut by functional domain. Japan owns Japan-specific features from UI to data

Size set by budgetThree people: thin. Eight: over-engineered

Team size doesn’t match the module

Size teams by module complexity. Five needed, five given

Build teams from whoever you can hire, and recruiting decides your architecture. Draw the product first, the organization after.

Figure 1. A company that put mobile and backend under two different leads had two login flows and two sets of error messages a year later, because a product copies its organization’s communication structure, so draw the target architecture first and lay team boundaries on module boundaries.

Most companies do it the other way round. They form teams from the people they can hire, then see what product those teams can build. In a tight talent market that's understandable. The cost is that recruiting outcomes end up deciding your product architecture.

Decisions for an engineering team in Japan

First, a product's core module cluster sits in one physical location under one reporting line. The 50 meters from the previous post applies directly. People building two modules that need a fine-grained interface should sit together.

Second, the boundary between the Japan team and the overseas team has to match a real module boundary in the product. The most common mistake is splitting front end from back end, with the front end in Tokyo and the back end at HQ. That boundary is the densest interface in the whole product. Put a time zone and a language across it and the product breaks right there. A better cut is by functional domain. The Japan team owns a complete block of Japan-specific functionality, from UI to data, and HQ owns the shared platform.

Third, team size follows module complexity. Budget shouldn't set it. If a module needs five people, it gets five. Give it three and that part of the product is thin. Give it eight and it gets over-engineered.

Where this sits in the method

My order for organizational design is the two maps first (market and talent), then product, then sales, and organization last. Conway's law is why product comes before organization. The organization is there to serve the product. It's the same point I made in Your resume is a request to be put in a box: where you draw the boxes decides what grows inside them.

Look at the most visible seam in your product. Which line on your org chart does it follow?

In this series
Previous：Fifty meters apart, conversations stop
Next：Don't run a startup-stage entity like head office

← All articles