Communication is the key to understanding Conway’s law

I’ve heard people talk about Conway’s law many times throughout my career. However, I only recently understood the central insight that it is built upon.

Conway’s law can be traced back to a paper called “How do committees invent?”, which was published in 1968 and written by Melvin E. Conway. It states:

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

I believe that Conway’s law is true and relevant, because it matches my personal experience so well. But let’s explore the central insight that it rests upon.

A case study: package delivery

Let’s suppose your local postal service decided to build a new package delivery system. The new system is supposed to enable customers to register their parcels for delivery right from home.

For a fully functional system, a lot of aspects would have to be considered. But for the sake of this article we will explore just one user journey: parcel registration.

When a customer decides to register their parcel for delivery, they have to go through a shopping cart flow which will result in the creation of an order. Before the order can be completed, the customer will have to pay the associated postage fee.

Considering the size and complexity of that user journey, the developers decided to built the new system from two subsystems: order handling and payment processing.

Why communication is the key

For an order to be completed, those two subsystems must communicate. After all, an order can only be completed after it has been paid for. To make this possible, the order handling subsystem will have to delegate the fee collection to the payment processing subsystem.

In other words: the payment processing subsystem will have to offer some kind of interface and the order handling subsystem will have to conform to that interface.

Now, it is important to realize that the order handling subsystem can only conform to the interface under one precondition: the designers of the order handling subsystem must be aware of the interface.

And there is only one way that they can be aware of the interface: they have previously communicated with the designers of the payment processing subsystem.

This leads us directly to the central insight that Conway’s law is built upon: in order for two systems to interact, the designers of those systems must communicate beforehand.

There are multiple ways to communicate

I’d like to point out that this insight holds true, regardless of who designs the payment processing subsystem.

In a large organization, it is pretty likely that each subsystem would be built by a different department. In this scenario, you could probably expect a lot of meetings, resulting in the creation of an informal api contract.

If both subsystems were designed by one and the same team, then the members of that team must communicate to get the systems to work together. It’s quite likely that most of this communication will happen informal and through face-to-face conversations. It might even take part through sharing the source code with each other.

But even if the designers of the order handling subsystem decided to integrate with a third-party payment processor, communication would still be necessary. In that case the majority of communication would probably occur via documentation like developer guides and an api reference.

Conclusion

As we just established, in order for two systems to interact, the designers of those systems must communicate beforehand.

Without communication between the designers, there won’t be communication between subsystems.

This is exactly why organizations tend to design systems whose structure mirrors the communication structure of the organization.