About half a century ago Mel Conway stated the following law:

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

In other words he stated that the shape of the organization dictates the shape of the system. There are many implications of this law. For one, it makes it apparent that the design of the system starts from the very moment the organization is created, and that certain classes of designs are essentially rejected before the actual work starts. This is already thought provoking enough, but my favorite consequence is that if you are to understand a system, you also have to understand the organization that created it. And if we take it a step further, we can get a glimpse of the organization by looking at the system.

My favorite story comes from an early experiment on understanding how developers communicate by using Ownership Map. The Ownership Map is a visual approach to reveal what parts of a system are changed by which developers at what point in time. The picture below shows an example: a horizontal line represents a file in time, a dot shows a commit, and a color designates an author. Several authors work on this system for a longer period of time: red and cyan mostly working on the upper part, and green, blue and red on the lower part.

There are a number of collaboration patterns that we extracted from this kind of visualization, but for this discussion I would just want to draw your attention on the bottom left. While in most other areas we can see collaborations between multiple authors (shown by commits of different colors next to each other), in this area green worked basically alone for a significant amount of time. This was awkward and we got curious. It turned out that green did not have a second chair next to him, and thus he ended up working alone.

Conway was right. The organization does influence the shape of the system. But, he was incomplete^{tiny note}.

His law only reveals half of the story. We know from physics that any action generates a reaction. My father, who is a physics teacher, uses a simple experiment to convince 12-year old pupils of this: he asks them to hit a table with their palm and then asks them if they feel any pain. As the table inevitably hits back, he successfully makes his point.

Conway says that the organization exercises a force that shapes the system in a way that mirrors the structure of the organization. But, just like the table hits back, so does the system. The organization is influenced by the system, too.

Before entering the research world, I worked as a software engineer at a 25-people software company in Timisoara. The company basically fed from one large project that kept most of its engineers busy. The project was a couple of years old.

As I got to know my colleagues more, I heard stories about how the company started with only a handful of people. Even if at the time they were all working in a small apartment, they had fun. Each person had a clear role (e.g., architect, developer or tester) and the project advanced well.

A couple of years later the situation was significantly different. The room turned into a cosy house with a nice garden, but the fun was pretty much gone, at least from this project. No one had clear roles any longer. Instead, they were all doing pretty much one thing: bug-fixing.

What happened? Even if the project started with the best of intentions, as the system grew larger it got a cranky personality and the team suddenly found itself spending almost all the time fixing bugs. Did they actually want to fix bugs? Not really. They would rather design new things and implement cool features. It was the system that forced them to do something else than what they wished. In other words, the system impacted the organization.

In general, when systems are small, we can shape them exactly the way we want without feeling their reaction. As they grow larger they have a say in what is happening.

Conway was right, but he was incomplete. Here is my law:

Both the organization and the system it produces evolve continuously as a consequence of a complex bidirectional interaction.

In other words, if you want to understand what is happening and to figure out what to do about it, you might want to look at the problem globally, because it might very well be that the actual problem is on the other side of the fence.

^{tiny note} Ever since I heard "Adam Smith was incomplete" from Beautiful Mind, I too wanted to say that someone was incomplete.