Conway's law: draw the team before the product

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

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 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: give a compiler to three teams and you get a three-pass compiler.

The reason isn't mysterious. Two modules need an interface, and the interface is negotiated by the people on each side. Teams that talk a lot produce fine-grained interfaces; teams that rarely talk produce coarse, duplicated, each-to-their-own ones. The seams in the product grow along the seams in the organization.

The dispute isn't whether the law is true but how strong it is. Empirical studies in open source and enterprise software have found the correspondence; others argue it's a tendency rather than a law, and that a good architect can deliberately cross organizational boundaries. My view: the tendency is strong enough that if you don't design against it, it will design for you.

Running it backwards

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

Three steps. Draw the target product architecture: how many major modules, where the boundaries are, which boundaries need tight coupling and which can be loose. Draw teams to match the modules: each cluster of tightly coupled modules goes to one team, and team boundaries coincide with module boundaries. Only then hire: define roles from team responsibilities, not teams from who is available in the market.

Most companies do it the other way around: form teams from the people they can hire, then see what product those teams can build. In a tight talent market that's natural, but the cost is that the product architecture is decided by recruiting outcomes.

Three concrete decisions for an engineering team in Japan

One: 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 interface sit together.

Two: the boundary between the Japan team and the overseas team must coincide with a real module boundary in the product. The most common mistake is splitting front end and back end: front end in Tokyo, back end at HQ. That boundary is the densest interface in the whole product, and with a time zone and a language in between, the product breaks along it. The 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.

Three: team size follows module complexity, not budget. 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's over-engineered.

Back to the method

My order for organizational design is two maps first (market and talent), then product, then sales, then organization last. Conway's law is the theoretical basis for the "product before organization" step: the organization serves the product, not the reverse. It's also the same point as Your resume is a request to be put in a box: where you draw the boxes decides what grows inside them.

The most visible seam in your product: which boundary on the org chart does it correspond to?

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