Conway's Law of systems design: The most important 4-pager that nobody has ever read

Have you ever heard of Melvin Conway? He might be the person that has written the most important paper you have never heard of. Let's dive into the nature of designing systems.

Have you ever heard of Melvin Conway? He might be the person that has written the most important paper you have never heard of. In 1968 he wrote a short and concise 4-pager about how organizations design systems. It’s pretty well-known among software people. However, it actually has nothing to do with software. Here is the part that came to be known as Conway’s Law:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. 

Or in other words: Any system design will naturally mirror how and how often the people that have designed the system have communicated with each other during that design phase - or not.

Any flaws or shortcomings in the communication between team members or teams will be reflected in shortcomings and flaws of the system design. Now what is a system? It can really be anything. Conway describes systems design the following: 

That kind of intellectual activity which creates a useful whole from its diverse parts may be called the design of a system. 

He cites computer programs and military strategies as examples, but every product or service can be considered as well, or even baking recipes for Christmas cookies. 

It is relevant to understand that the flaws and shortcomings already start to creep in at the very beginning of a systems design project, before it even has started: 

The very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise.

The moment you even start thinking about how to organize the design effort, you have already made (implicit) decisions that limit the paths you can pursue from there on. 

Let’s say you want to bake Christmas cookies together with two friends. The moment you decided to ask two particular friends and not certain others, you have included certain recipes and skills that the three of you together possess, and excluded many others. It’s highly unlikely that you have chosen the perfect skill set for the perfect cookie making project (even though the experience itself with your friends might be outstanding and worth it - but you get the idea). From there on, it only gets worse, by default:

Once the organization of the design team is chosen, it is possible to delegate activities to the subgroups of the organization. [...] It is a natural temptation of the initial designer - the one whose preliminary design concepts influence the organization of the design effort - to delegate tasks when the apparent complexity of the system approaches his limits of comprehension. 

Subdivision is the enemy of system-level performance! Granted: Subdivision is necessary, because most systems are just too complicated to be designed alone. The three of you might be able to manage the cookie factory as a group, but you for sure can’t design and build a house with that same group of three. You would need to make it bigger and more subdivided. But once subdivision and hence task delegation is introduced as an antidote to complexity, the flaws that you have introduced into your design - by definition by just deciding to start with designing - get multiplied:

Every time a delegation is made and somebody's scope of inquiry is narrowed, the class of design alternatives which can be effectively pursued is also narrowed. 

Think about it: Once you decide that e.g. dough making, cookie decoration and oven management is what matters to great cookies, you will delegate dough making to one of your friends, cookie decoration to the other, while keeping the job of oven management for yourself. You now have 3 functions, and all they can achieve now is their own subdivided function, in isolation. You need to communicate has increased, because two of the three functions now don’t know anymore what the rest is doing. Furthermore, all the 3 of you can achieve now is what is possible with those 3 functions - unless you change your organizational approach (e.g. deciding that dough and decoration should actually be one function, or by bringing in a novel function in the first place).

And guess what? It gets worse from here on! Since now you have those 3 functions, none of you 3 want to get bored while waiting for the rest to finish their tasks, right? So here is what will happen:

Once the organization exists, of course, it will be used. Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organization in need of work.

As a natural tendency, over time your holistic “Cookie Company” will develop into rather separate dough making, decoration and oven management units. And the moment each unit has grooved into a working mode, it’s a natural tendency to just keep on doing that - and even do more of the same, in fancier ways. None of the units now is necessarily thinking about the actual cookie making goal anymore. Or in other words: Once you have subdivisions and teams, the natural tendency is for each team to optimize their respective subdomain. This tendency is inevitable, by default - unless you do something about it. 

We now have reached the central conundrum that Conway points out in his paper: System complication leads to division and delegation during the design phase. This leads to artificial subsystem boundaries, which leads to communications breakdowns. Those lead to subsystem optimization, which leads to flaws in the eventual system performance and inferior outcomes:

This is the turning point in the course of the design. Either he struggles to reduce the system to comprehensibility and wins, or else he loses control of it.

So here is the trade-off systems designers have to make: They have to accept that “loss of control” is almost a given for a sufficiently complicated design project, because control necessarily moves to the subdivisions. There is no other way (for the time being, which might change with a sufficiently smart AI system), which is why you can’t beat Conway’s Law. But you still need to constantly fight it (or give up and accept inferior standards). Now two approaches start to matter: 

Incentives to coordinate: Always remind teams and subdivisions why they are here, what the overarching system goal is. Make them understand what Conway’s Law is and that it is everyone’s job to push against its inevitable consequences. Think hard about a carrots-and-sticks approach that can support you here, because it’s the only viable option you have:

Coordination among task groups, although it appears to lower the productivity of the individual in the small group, provides the only possibility that the separate task groups will be able to consolidate their efforts into a unified system design.

Simplification: Keep on making your system architecture simpler! Make sure to avoid too much subdivision by simplifying the system and its subcomponents. You will overly subdivide and complicate the system initially, by definition, because it’s the natural impulse when faced with incomprehensibility. So constant simplification, revision and re-design is the way to go (the earlier, the cheaper). Establish a constant drive towards that, always in line with the system goals. It might come with further reorganization, but that’s the entire point of systems design. Which eventually brings us to the core action that can be derived from Conway’s Law: 

Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design. [...] A design effort should be organized according to the need for communication.

If you want to build great products, then rigid org structures with siloes, stiff hierarchies, strict reporting lines and waterfall planning lead the way straight to hell. Design, development, production, testing, “the business”, the tech people, marketing, the accountants etc. are not separate things. Just because you have separate teams, does not mean they work on separate goals. They are basically aspects of the same thing: Building technology together. This requires (constant) communication between people with different skills in order to figure out the best (and most viable) design, quickly, irrespective of artificial department boundaries.

Unfortunately, we now live in a world in which basically everything is defined and driven by technology. So building things in the age of technology means constant communication, improvements, flexibility and the ability to think in systems, as a default. Deal with it - or risk being left behind.