Conway’s Law is not a warning, it’s a design tool. The shape of the team that builds a system is the shape of the system. Here’s how we use that on purpose.
Conway's Law is usually quoted as a warning: "organizations design systems that mirror their communication structure." The implication is that if your org chart is a mess, your architecture will be a mess. That is true. It is also not very useful.
The useful version is the inverse. If you know the architecture you want, you can work backwards to the org chart that produces it. Team topology becomes a design tool, not a symptom. We use this on every engagement.
The two questions we ask first
Before we write a line of code, we ask: what are the seams? Where does one team need to talk to another to get work done? Every one of those conversations is going to calcify into an API boundary. If two teams talk constantly, the API between their services will be chatty and coupled. If they barely talk, the boundary will be clean but the product integration will suffer.
"The shape of the team that builds a system is the shape of the system. You do not get to opt out of this."
Second question: who owns the on-call for each piece? On-call is the real test of ownership, because it is the moment where politeness breaks down. If a team owns a service on paper but pages another team when it breaks, that team does not own the service. The page tells you the truth.
Designing teams on purpose
The best engagement we ran this year was one where the client asked us to redesign their platform. We delivered, instead, a recommendation that they reshape their engineering org first, and then the architecture would fall out of it. They did. It did. Six months later the platform that had been stuck for two years shipped cleanly.
This is not a magic trick. It is just taking Conway's Law seriously. If you try to build a platform with a product-shaped team, you get a platform that looks like a product. If you want clean service boundaries, you need teams with clean human boundaries — shared goals, shared on-call, and a short-enough communication path that they actually collaborate.
We now open most engagements by drawing two diagrams before we draw any architecture. The first is the target system. The second is the team shape that would plausibly produce it. If the second diagram looks nothing like the client's real org chart, we have a different conversation to have first.