Conway’s Law says that organizations tend to design systems that mirror how their teams communicate.
Melvin Conway first described the idea in his 1968 paper, How Do Committees Invent? He put it this way:
Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
In software, the simplest version is:
Your architecture tends to look like your org chart.
Imagine three teams that operate mostly independently from one another. Over time, the system is likely to develop boundaries that reflect those teams, with each team owning its part and coordinating changes through interfaces and contracts.
Put the same people on a single team, and those boundaries become cheaper to cross. The resulting system is more likely to evolve as one closely connected system rather than several independently owned ones.
This happens because a change is usually easier to make within one team than to coordinate across multiple. And the places where teams have to coordinate become interfaces between their systems. Ownership boundaries become system boundaries. Eventually, the communication structure of the organization starts showing up in the architecture.
The effect can go deeper than service boundaries. Different teams can develop their own terminology, data models, abstractions, deployment processes, and interpretations of the same business concepts.
Architectural decisions start making more sense when you look at the teams and communication paths behind them.
The Inverse Conway maneuver can help: instead of accepting that your organization will shape your architecture, deliberately organize teams around the architecture you want.
For example, if you want independently deployable systems, give each system to a team that can build, change, and ship it on its own. If two components need to evolve together, keep the people responsible for them on the same team.
Conway’s Law is not really about org charts. It is about the friction of communicating across boundaries. Where communication is easy, the software tends to grow together. Where it is difficult, it tends to split apart. And that is how your org chart becomes your architecture diagram.