Ship the org chart

Melvin Conway noticed it in 1967, and it has aged better than most things from 1967: any organisation that designs a system will produce a design whose structure copies the organisation’s own communication structure. Put less formally, a system ends up shaped like the team that built it.

It is tempting to treat that as a curiosity. It is closer to a law. If three teams build a product and two of them barely speak, you can predict where the product will be brittle: at the seam between those two teams. The awkward integration, the data that doesn’t quite line up, the feature that needs a meeting to change, they map almost exactly onto the gaps in the org chart. The communication structure is the architecture, drawn in a different tool.

Once you see it, the consequence is hard to avoid: architecture and organisation are the same problem. You cannot decide the shape of the system and the shape of the team separately and hope they meet in the middle. They will meet, but on the org chart’s terms. If you want a clean boundary in the system, one side able to change without breaking the other, you need a clean boundary in the team first: a clear owner, a real interface, a reason not to reach across. If two parts must move together, the people who own them have to be close enough to move together too.

You ship your org chart, in the product, whether you mean to or not.

The useful version runs the law backwards. If the system is going to copy the org, then shape the org to get the system you want. Teams built around the products, not the technologies. A boundary in the company wherever you want a boundary in the code. This has a name, the inverse Conway manoeuvre, but the name matters less than the habit: design the org chart as deliberately as the system diagram, because it is going to become the system diagram.

If you want a clean boundary in the system, you need one in the team first.

It also explains something about building alone. When the whole org chart is one person, there are no seams forced by team boundaries, and the system can be as coherent as that person can hold in their head. It is a real, and underrated, advantage of small. It is also the ceiling, because one head only holds so much. Either way, the structure of the thing maps onto the structure of the builder.

So the org chart is not an HR artefact sitting to one side of the real work. It is a design document. The only choice is whether you drew it on purpose.