Conway's Law gets quoted as an observation: "organizations which design systems produce designs whose structures are copies of their communication structures."
It's usually delivered with a shrug. The system mirrors the org chart. What can you do?
Quite a lot, actually.
Conway's Law can be used deliberately. If system structure follows communication structure, then architecture work includes the communication paths around the system.
Most teams do the reverse. They draw the architecture they want, leave the communication paths alone, and act surprised when the old org reappears in the new services.
The law is bidirectional
The quote says the system mirrors the org. The implication most teams take is: if you don't like the system, reorganize the org.
That is the cleanup version: notice the problem, then move the boxes.
The forward approach is more powerful: design the org to produce the system you want.
If you want service boundaries that match domain boundaries, you need team boundaries that match domain boundaries. If you want a clean interface between the payment system and the order system, you need a clean communication path between the payment team and the order team. If you want two services to be loosely coupled, you need two teams that can operate independently.
The system follows the communication structure. So design the communication structure first.
Most teams design the system, then hope the org adapts. It will not. The org will pull the system back into its shape, because communication paths are where coordination happens, and coordination is what shapes interfaces.
The coupling you can't remove
Reliability is an organizational problem. So is coupling. The coupling between services is determined by the coupling between teams, and no amount of architectural cleanup will fix service coupling if the team coupling doesn't change.
It starts clean. Two services. Two teams. A decent API contract.
Then a feature requires changes to both services. The teams coordinate. They meet, negotiate, ship, and update the API to reflect the coordination.
Do this ten times, and the API contract turns into a coordination surface. The services become coupled through the work the teams repeatedly had to coordinate. The coupling was inevitable the moment shared features kept crossing the boundary.
Conway's Law is doing the work here. Two teams coordinating on shared features produced two services with a coupled API.
You do not fix that by redesigning the API. You fix it by redesigning the communication structure: merge the teams, or split the feature so each team owns its part independently.
Inverse Conway maneuver
The deliberate version of this is called the Inverse Conway Maneuver. You want a specific system architecture. You design the org chart to produce it.
Want microservices with clean domain boundaries? Organize teams around domains, not layers. Don't have a "database team" and a "backend team" and a "frontend team." Have a "payments team" that owns the payment service end to end. The system will follow.
Want a platform other teams can build on? Create a platform team with a clear interface, then give product teams the autonomy to use it without a meeting. The system will develop a clean platform boundary.
If every team has to talk to the platform team to ship, the platform boundary functions as a coordination surface. Calling it an API does not change the operating model.
The maneuver works because it removes the coordination that creates coupling. If two teams don't need to talk, their services don't need to couple. The communication structure produces the system structure, and you control the communication structure.
When it fails
The Inverse Conway Maneuver fails when the org change is cosmetic. You reorganize into domain teams, but the reporting structure, the review process, and the deployment pipeline still require cross-team coordination. The communication structure didn't actually change. Only the org chart did.
This is the common failure mode. Teams reorganize, declare themselves domain-oriented, and nothing changes because the real communication structure did not move.
Who approves what. Who owns which deploy. Who gets paged for which incident.
The system stays coupled because the coordination stayed coupled.
Ownership is not a file. The same principle applies here. Reorganizing teams without changing ownership boundaries changes the label without changing the responsibility. The system knows the difference, even if the org chart does not.
The maneuver also fails when the architecture you want does not match the problem.
If payment and orders genuinely need to coordinate on every transaction, splitting the teams creates a coupled system with a worse communication structure. Now two teams fight over a shared boundary instead of one team owning it.
Conway's Law does not care what you want. It describes what the communication structure will produce. If the communication has to be tight, the system will be tight, regardless of how you drew the org chart.
Conway's Law is useful because it gives architecture a social surface area. If you want different boundaries in the system, the communication paths around those boundaries have to change too.
The one-line version
Conway's Law is useful when team boundaries, ownership, and communication paths are designed with the system architecture in mind.