📖 Business
Conway's Law as Strategy
In 1967, Melvin Conway observed: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." For decades, this was treated as a cautionary tale — a warning that org structure leaks into architecture whether you want it to or not. Skelton and Pais flip this on its head, treating Conway's Law not as a problem to avoid but as a strategic lever to pull. If the architecture you get is determined by team structure, then design your team structure to produce the architecture you actually want. They call this the "Reverse Conway Maneuver."
2
Minutes
2
Concepts
+45
XP
1
How It Works
Conway's Law operates whether you acknowledge it or not:
- A single "mobile team" will produce a single, monolithic mobile app — even if the business needs independent mobile experiences per product line. The team's communication boundary becomes the software boundary.
- Separate frontend and backend teams will produce a layered architecture with a heavy API contract between them — because that's the communication boundary between the teams.
- Three teams assigned to build a compiler will produce a three-pass compiler. Not because three passes is optimal, but because three teams need three pieces of work.
The Reverse Conway Maneuver: deliberately restructure teams to match your desired architecture before building it. If you want microservices, organize teams around services first. If you want a modular monolith with clean domain boundaries, organize teams around domains first. The architecture follows.
Key constraints:
- Team communication bandwidth is finite — Dunbar's number applies. Teams of 5-9 people have natural communication limits that create natural software boundaries.
- If two teams need to communicate heavily to build a feature, their services will become tightly coupled. Either accept the coupling or restructure so one team owns both pieces.
- "Org chart" reporting lines are irrelevant — what matters is the actual day-to-day communication patterns.