We drew a clean architecture on the whiteboard and shipped a different one. Six months later the running system did not match the diagram. It matched the org chart.
This is Conway’s Law, and everyone has heard the one-line version: organizations ship their communication structure. You nod, you file it under “interesting,” and you go right on believing that with enough discipline you can build the architecture you designed regardless of how the teams are arranged. I believed that for years. I was wrong in a specific and expensive way, and I want to be precise about how.
Picture the setup. A marketplace business I ran, a few hundred engineers spread across four countries, several time zones between the ends of it. We had drawn service boundaries the way you are supposed to: around capabilities. Catalog here, pricing there, fulfillment over there. Sensible. Then we staffed it the way headcount and hiring and office leases actually let us, which is to say not aligned to those boundaries at all. The pricing logic lived in a service, but the people who understood pricing were split across two cities and reported up two different chains.
You can guess what happened. The seam that was supposed to run between catalog and pricing slowly moved. It crept until it sat between the two cities instead, because that was where the real communication cost was. Every change that needed both cities to agree got slow, got an extra meeting, then got an API in front of it so the two sides could stop needing to agree. The architecture rearranged itself to route around the org’s friction. It always does. The friction is the gravity and the code is the water.
The part nobody tells you
Here is the part nobody tells you about Conway’s Law: the version that bites you is not the system mirroring the org. It is the system mirroring the org badly, because the org and the intended architecture were never aligned in the first place. When they match, you get clean boundaries that nobody has to fight. When they fight, you get a system that is half your design and half a scar map of every place two teams could not talk cheaply.
So you have two real options, not one. You can keep your architecture and reshape the org to match it. Or you can keep the org and let the architecture follow, and at least it will follow something coherent. What you cannot do, what I spent too long trying to do, is hold a target architecture fixed while the org pulls against it and expect the architecture to win. It will not win. It will just become a worse version of itself with extra integration glue, and you will spend your incident reviews discovering that the glue is where everything breaks.
Once I accepted that, the whole thing flipped from a tax into a tool.
Using it on purpose
If teams produce architecture, then the team boundary is the most powerful design decision you make, and you make it in the org chart, not the codebase. I started designing the org first and treating the system as the output.
Want two services to have a clean, stable contract between them? Put a real team boundary there. Give each side its own on-call, its own roadmap, its own manager, and make the interface between them the thing they negotiate. They will harden that interface because crossing it is expensive for them, and an interface that is expensive to cross is an interface that gets defined well and broken rarely. That is what you wanted from a service boundary in the first place.
Want two pieces of logic to stay flexible and tightly coupled, to change together without ceremony? Put them on the same team. Do not split them across a boundary just because the diagram has two boxes. The diagram is cheap. The boundary is not.
The cost of a team boundary in the wrong place is the thing I would attach a number to if the number were not embarrassing. A boundary drawn where two teams need to change things together, constantly, does not stop them needing to change things together. It just makes every joint change a cross-team negotiation, then a versioning problem, then a backlog of “blocked on the other team” tickets that nobody can close. You pay that rent every sprint, forever, until you move the boundary. (We moved one. The relief on both teams was visible in the next planning meeting.)
Time zones are the honest part
The four-countries detail is not color. It is the mechanism, and it is the cleanest illustration I have of why this is real.
A team boundary inside one office is soft. People talk in the hallway, the boundary blurs, coupling sneaks back in because it is easy. A team boundary across a wide time zone gap is hard whether you wanted it to be or not. When the overlap in the working day is two hours, every dependency that crosses that gap costs you a day of round trip. You learn fast which dependencies you can afford and which you cannot.
So the time-zone seams became API seams, and honestly they became our best ones. Across the seam where two teams shared most of the day, the contract stayed loose and a little sloppy, and it cost us in subtle coupling we did not notice until later. Across the seam where the overlap was two hours, the contract got formal, asynchronous, well documented, and versioned, because nothing else survives a one-day round trip on a clarifying question. The geography was telling us where to put our hardest interfaces. We just had to read it as a design input instead of an HR problem.
That is the reframe. Stop treating the org chart as a constraint on the architecture and start treating it as part of the architecture, the part with the longest lead time and the highest cost to change. Moving a service is a refactor. Moving a team is a quarter of churn and some bruised reporting lines, which is exactly why the boundaries it creates are the ones that hold.
I do not draw the system first anymore. I draw who talks to whom, and how cheaply, and then I let the boundaries fall where the conversation is already expensive. The system that comes out of that is one I actually get to keep.
So before your next big architecture, go look at the org chart. It already shipped the answer. The only question is whether you drew it on purpose.