By Stephan Schulze
Conway’s Law, introduced back in 1967 by programmer Melvin Conway, says:
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin Conway
In other words, your system architecture reflects your team structure and ways of communication.
How does the law apply to a typical tech team divided into frontend, backend, and infrastructure? Well, the apps that they build usually reproduce this structure:
- A standalone deployable frontend that interacts with a separate backend.
- The backend team deploys the code.
- They then hand over the operations to the infrastructure team.
This somewhat instinctive organizational mirroring presents several productivity challenges:
- The frontend team can’t release new features without the backend team.
- The backend team is equally dependent on DevOps for insights (logs etc.).
- The infrastructure team handles the operations of an app they’re not familiar with.
Reviewing your teams or architecture from the perspective of Conway’s law helps you shape either:
- If you start by migrating into a distributed, service-oriented architecture, your teams’ structure and communication will probably develop into service-focused crews (aka Inverse Conway Maneuver);
- if you begin by creating product-oriented teams, your system architecture will likely evolve accordingly.

Check my LinkedIn post for more community insights, and share your thoughts.