Conway's Law

You join a new company as a software architect. The team is small, everybody sits together, and communication is easy. You turn your head, ask a question, get an answer, and keep moving.

In that setup, the architecture will usually reflect the same closeness. A modular monolith often fits well because the people building it are tightly connected too. That is exactly what happened here.

New Team in a Different Location

After a few months, the business wants more features than one team can reasonably deliver. A second team is added quickly, which sounds helpful until you hear one detail: they are in another city.

So now the architecture has a new dependency. Not a database. Not a queue. Distance.

You try calls, screen sharing, and regular sync meetings. It works, up to a point. Then the other team starts interpreting the existing architecture differently, because of course they do. They are not in the room where the assumptions live.

Soon, the cost of constant clarification becomes obvious. More people means more communication paths, and distance makes each of them slower and less reliable. Splitting work into microservices suddenly looks less like a trend and more like a response to the shape of the organization.

Another Team in a Different Timezone

Then another team joins, this time in a different timezone.

At that point, synchronous communication stops being the default. When one team starts work, the other is wrapping up or sleeping. Meetings become expensive. Shared understanding gets thinner. More autonomy becomes less of a luxury and more of a survival tactic.

So the system evolves again. Services become more independent because the teams building them are more independent.

Conway’s Law

The solution you arrived at is an example of what Melvin Conway observed in 1968:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

That is exactly what happened here. As communication became less direct, the architecture became more segmented. What used to work as a shared monolith was restructured into separately deployed units because the teams themselves had become separately organized units.

Chris Ford once said to Martin Fowler:

Conway understood that software coupling is enabled and encouraged by human communication.

The easier it is to talk to the people who own a part of the system, the easier it is to understand and change that part. Once communication gets slower, architecture usually compensates by creating stronger boundaries.

That is why Conway’s Law is useful. It is not just a clever quote for architecture talks. It is a warning that team design and system design keep shaping each other whether you acknowledge it or not.

The Attitude

In Martin Fowler’s experience, every project he has participated in has confirmed Conway’s Law in one way or another. The usual reactions still look familiar.

1. You Accept It

This is the useful response. You treat the law as a constraint worth designing around. Maybe your case will be different, but betting against a repeated pattern should at least be a conscious decision.

2. You Don’t Care

You can do this. Teams do it all the time. The usual result is that reality keeps applying the law anyway while everyone acts surprised by the coordination pain.

3. You Let the Tail Wag the Dog

Fowler also points to the Inverse Conway Maneuver, coined by Jonny LeRoy and Matt Simons. In that approach, you change team communication on purpose so the architecture changes with it.

That can work, but it is not free. Reorganizing teams to reshape a large system can create its own disruption, especially in legacy environments. Useful move. Not gentle.

Final Thought

Conway’s Law matters because it explains a pattern teams keep rediscovering the hard way: communication structure leaks into system structure.

Ignore that if you want. The architecture usually will not.