Skip to content

Conway's Law

Systems mirror the communication structures of the teams that build them.

“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

Originally published in How do Committees Invent? by Melvin E. Conway. Later dubbed Conway’s Law by Fred Brooks in the Mythical Man-Month.

Yes. Stronger than ever in distributed teams.

Conway’s Law reminds us that technical architecture and organizational structure are deeply intertwined. If your teams are siloed, your architecture will reflect those silos — often with painful consequences. This law is especially relevant when adopting microservices, distributed systems, or platform teams. To avoid unnecessary friction, leaders must intentionally shape team boundaries, communication paths, and incentives to reflect — or influence — the system architecture they want to see.

This law also underpins the value of cross-functional teams and platform consistency efforts. The inverse is also true: poorly aligned team structures will often sabotage even the best technical intentions.

Multiple people have pointed out that Conway’s Law has at least one corollary:

“People will adapt the explicit systems they got to fit the implicit real-world business concepts.” - Sven Balnojan1

“If a system is designed in a manner that is the antithesis to the structure of its supporting teams, the system will fail.” - Keith Chester2

The Inverse Conway Maneuver is an organizational design strategy that intentionally flips Conway’s Law on its head. The term was first coined by Johnny LeRoy and Matt Simons in December 2010 and was further popularized by Matthew Skelton and Manuel Pais in their book Team Topologies in 2019.

  1. How Conways Corollary Wrecks Your Data Organization by Sven Balnojan

  2. Conway’s Corollary by Keith Chester