conways-lawlisted

# Conway's Law > "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." > — Melvin Conway, 1968 ## The core idea Conway observed that the architecture of a software system will mirror the communication structure of the team that built it. If you have three teams, you'll probably end up with a three-tier system. If two teams don't talk much, the interface between their systems will be poorly defined and brittle. This isn't a choice — it's an emergent property of how organizations work. This isn't a bug to fix. It's a force to work with. ## Why it matters - **Org structure drives architecture** more than technical decisions do. The seams in your software tend to appear where the seams in your org appear. - **Communication overhead is the bottleneck.** Dense, constant communication produces tightly integrated systems. Sparse communication produces loosely coupled systems. Neither is universally good — it depends on what you're building. - **Migrations are org problems, not just tech problems.** If you want to decouple a monolith into microservices, you probably also need to change how your teams are structured. ## The Inverse Conway Maneuver Once you accept Conway's Law, you can use it intentionally. The **Inverse Conway Maneuver** is: *design your team structure to match the architecture you want.* If you want a clean boundary between billing and user management, put thos