In 1967 Melvin Conway observed that “organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations.” It gets quoted a lot, usually with a knowing nod, and then ignored completely the moment anyone actually starts drawing boxes.
I’ve watched it play out too many times to treat it as a curiosity. Conway’s Law isn’t a warning about something that might happen. It’s a description of what will happen. The only choice you get is whether it happens to you, or because of you.
What it actually looks like
The textbook version sounds abstract. In practice it’s concrete and a bit depressing:
- Three teams build a system, and you get three services — not because three was the right number, but because there were three teams.
- A feature that needs two teams to cooperate quietly never gets built well, because the communication path between those teams is a fortnightly meeting and a shared Jira board.
- The seams in the architecture land exactly on the org boundaries — and the integration pain lands there too, because that’s where the conversations don’t happen.
The system is a cast of the gaps between your teams. Wherever people don’t talk easily, you’ll find a brittle, over-formalised interface. Wherever they do, you’ll find things mushed together that probably should have been kept apart.
And it runs both ways. The org shapes the system, but the system then shapes the org right back: once those over-formalised interfaces exist, working across them is expensive, so teams stop trying, the silos harden, and the next system gets built to the same contours. Inflexible, siloed systems reinforce the very silos that produced them. Left alone, the org chart and the architecture quietly lock each other in — and every year the loop is harder to break.
The Inverse Conway Manoeuvre
Once you accept that the org shape leaks into the system shape, there’s an obvious move: design the org for the architecture you want, rather than letting the architecture congeal around the org you happen to have. This is the so-called Inverse Conway Manoeuvre — shape the teams, and the boundaries follow.
It works, within limits. If you want loosely-coupled, independently-deployable services, you need loosely-coupled, independently-operating teams to build them. No amount of clever API design survives contact with two teams who have to coordinate every release.
But it’s not a magic wand. I watched this play out on a transformation programme that stood up a dedicated cross-functional team to rebuild a core platform — exactly the manoeuvre above. For the architecture, it worked: freed from the functional silos that had calcified the old system, the team built something genuinely modular. But the team itself quietly became a new silo. Its internal vision was crisp and well-aligned; the trouble was that vision had drifted from the rest of the business. Decisions that needed sign-off outside the team stalled. Resources it didn’t own didn’t show up when they were needed. And the culture it was trying to build couldn’t be set from inside a single team — it had to come from the organisational level, and getting that across to the executive was the hard part.
So the manoeuvre had done its job on the system boundaries and quietly moved the pain to the org boundary around the team. Re-orging is expensive, slow, and political in a way that drawing a new diagram is not — and it doesn’t abolish Conway’s Law so much as relocate it.
What to actually do about it
- Read the org chart as an architecture diagram. It already is one. Before you design the system, look honestly at who talks to whom, and how often.
- Put the seams where the silence is. If two teams barely communicate, don’t design something that needs them to integrate tightly. You will lose.
- Lower the cost of the conversations that matter. Sometimes the cheapest architectural fix is not a new service — it’s getting two people in the same room (or channel) regularly.
- Use team shape deliberately. If you’re lucky enough to influence team boundaries, treat that as an architectural lever, because it is one — arguably the most powerful you have.
The uncomfortable bit
Conway’s Law means a chunk of your architecture is decided by people who have never seen the codebase — in reorgs, in hiring plans, in who-reports-to-whom. As architects we like to think the design lives in our diagrams. A lot of it lives in the org chart, and it was decided months ago.
The trick is to stop fighting that and start using it. Draw the org chart next to the architecture and ask yourself which one you’re really designing — because you’re always designing both, whether you meant to or not. Conway’s Law is going to write itself into your system either way. The only question, still, is whether it happens to you, or because of you.