Don't Fight It, Use It
Since Conway's Law is a powerful and unavoidable force, the correct response is not to ignore it or fight it — it's to leverage it deliberately. This leads to the Inverse Conway Maneuver (also called the Reverse Conway Maneuver), a concept popularized by the book Team Topologies by Matthew Skelton and Manuel Pais, building on earlier work by ThoughtWorks researchers.
The core idea is simple but radical:
If you want to change your software architecture, you must first change your organizational structure to match the desired architecture.
Reversing the Causality
Traditional thinking: design the software, then build it with whatever teams you have.
Inverse Conway thinking: design the software architecture you want, then design the team structure to match it, then let the teams build the software naturally.
Instead of letting the org chart dictate the architecture, you define the ideal architecture first and mold the teams to fit it. If you want a software architecture composed of independent, decoupled services based on business domains — a Payment Service, an Inventory Service, a Shipping Service — you must create independent, cross-functional teams responsible for those domains: a Payment Team, an Inventory Team, a Shipping Team.
By aligning team boundaries with desired software boundaries, you use Conway's Law as a design tool. The high-bandwidth communication within the Payment Team results in a cohesive, well-understood Payment Service. The low-bandwidth, contract-based communication between the Payment Team and the Inventory Team results in a clean, stable API between those services.
The Sequence Matters
The maneuver only works if you change the org structure before or simultaneously with the architectural change — not after. If you split the monolith into microservices first and then try to reorganize teams, you'll find that the new service boundaries don't match how people actually communicate, and the architecture will drift back toward the old shape within months.