Conways Law and Ownership

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

– Melvin E. Conway

Understanding Conway’s Law is a crucial aspect of navigating the complex landscape of modern software development, especially as teams become more specialized and distributed.

Here’s an example of Conway’s law: A company has a frontend team and a backend team, so their applications naturally have a clear boundary between the user interface and the data and business logic. This results in their application’s frontend and backend communicating over HTTP APIs. Concretely, this might mean they have a React.js application and many microservices that it talks to.

Conway’s law implies that your architecture will match your organization.

Ensuring you align your resources’ ownership with your organizational structure is important.

If you don’t get this right, the work will be inefficient and awkward.

For example, if you have an infrastructure team responsible for maintaining services’ Kubernetes deployment manifests, the Kubernetes deployment shouldn’t live within the services’ repository. It should live within a different repository that the infrastructure team owns.

Otherwise, the ownership model doesn’t align with the organization’s structure. There will be inefficiencies when the infrastructure team maintains the Kubernetes deployment manifests.

If you struggle with what team should own what at your company, align it with your company’s organizational structure. If that’s not the architecture you want, you’ll have to change the organization before changing the system’s design.

Conway’s Law can help us align our teams with our technology, making sure our work flows smoothly and our systems make sense.

---