Conway's law

Organizations tend to make systems which are copies of their lines of communication.

The original quote is “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”. — Melvin Conway, “How Do Committees Invent?”

In the most basic framing, if you have 2 people who need to coordinate task splitting among themselves. They’re going to agree to a boundary of some kind.

For example, if we need to handle the chore of dishes, we’ll step on each other’s toes potentially if we both try to do the activity. So we split it. If you load the dishwasher, I’ll unload it.

We pick something that feels natural to us. That split, however, create a communication point between the two of us, and we’ll need to establishes norms or signals to handle common circumstances. We’ll make systems. A classic simple one is perhaps a magnet to indicate the dish washer is full and has been run by a small sign on the front that we flip up.

This is again a simple and natural boundary. One that we feel needs no explanation. Certainly not as much as I’m doing here.

As we begin to scale up work, though, involve more people and specialization. Coordination points tend to stop happening between just point to point people. They tend to get collapsed through coordination points.

So let me show the progression by shifting domains and then slowly adding people.

Starting off with just 2 people, let’s have Jim is work on the frontend, and Nina work on the backend.

No problems whatsoever. Same as with the washing dishes scenario. We will have some simple processes we’ll develop over time to coordinate work. Probably slack channel.

The company grows and gets more customers, and those customers want more and so more people are hired to deliver more.

Suddenly, your development team is 12 people and you break it up into 2 groups, you’ll need to pick something. Lets do the same one that work before. Frontend and backend. Lets say 4 frontend and 8 backend.

That seemed to work well before, except now you need to coordinate. You don’t just peer directly any more to other people when working features. You got to the other team and you ask for them to do something. They add it to their task list.

After all this breaking down into different teams, for coordinating how the different parts will talk to each other, the natural channel becomes the lead or manager for each team. It doesn’t need to be this person, but it is the default many times.

And this right here is the core of Conway’s Law. Your organization design are the defaults for system design and the hierarchies in your organization and how those talk to each other.

Some claim this law is unbreakable, like Casey Muratori. Again, I find that to be overreach, but defaults have a strong effect. In point of fact, Casey describes in that video that the organizational chart of Microsoft can be seen across the time and the API design of the 1980s can be seen well into the 2010s.

In practice:

Since these communication channels are your defaults, maybe don’t fight it and rather instead be intentional with how you orgnize it.

Perhaps you can do the famous “feature team” design, where you stack a cross functional team on an area. That said, there’s still a risk that the team names parts of the system after itself, as did the DirectX team in Windows.

But maybe you can just not make it too neat and clean. You could do like Nan Yu, Head of Product at Linear, talked about how their teams are somewhat broken down by skills, but then it stops there. There’s a very large product engineering team that does work, but inside of that are several features and systems, and there is no explicit ownership of who works on what.

In particular he called out how the design of the organizational chart doesn’t look nice and symmetrical. It’s distinctly not eye pleasing to look at. He called their org chat an “heirloom tomato.”

In many ways this is somewhat the argument of the Cathedral and the Bazzar by Eric Raymond, where rather than making lots of clean lines. You simply let people naturally connect and let structure emerge as needed.