Conway’s law was defined in 1967 but it is as valid today as it was back then. According to it, each organization copies its structures into the solutions it develops. What does it mean and what influence does it have on us? The law itself sounds a little mysterious. However, it is profoundly related to the results of our teams’ work.
It is the first time I hear about it
As you might have realized, the initial euphoria of creating a new product or launching a new IT project is usually accompanied by the joy of designing its new architecture. We are talking, of course, about a solution that is consistent with current trends, based on the best frameworks and libraries, and developed with the latest versions of supporting tools. A true paradise, isn't it? The same thing happens when creating a new, large product version. We team up with good architects and designers, which at this stage is very easy. Then, the implementation stage begins. Suddenly, it turns out that our wonderful module-based or microservice-based architecture, which we´ve divided so well into technical and business domains connected by a thoroughly designed platform transforms itself into a strange monolithic or modular creation with an impenetrable network of co-dependence. To our surprise, our heroic battle to smooth out these co-dependencies only brings more of them. On the other hand, the technical debt is growing, even though we have barely just started. Does any of that ring a bell? But why? After all, everything was so perfectly designed! As it turns out, the reason may lay in the so-called Conway’s law, also named “the mirroring hypothesis.” Most of you have probably heard about it. But are we really able to draw conclusions from it and practically reduce the above-mentioned risks? That proves to be more difficult. But let us start from the very beginning.
Dura lex, sed lex!
What is the mirroring hypothesis? Is it actually a hypothesis, or is it a law? We normally tend to believe that a law is something that has been proven and confirmed, while a hypothesis is only an assumption. Nothing further from the truth! Even the most exact laws (e.g. physics) are but hypotheses. They only remain true until someone proves they are wrong. Let’s take the simplest Newton's second law of thermodynamics. If anybody ever proves that this law doesn’t work in our macro-world, it will stop being true. That’s the way it works and this is what the genius of people discovering such laws is about. The same thing happens in the fields that investigate social behaviors. The only difference is that they keep calling their findings a hypothesis, one that is statistically relevant, which means that there are studies that confirm given characteristics or relations occur in a sufficiently large number of cases.
Having clarified that point, let’s go back to Conway’s law, shall we? It says that: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure”. Sounds like mambo jambo, doesn´t it? Let’s try to crack it.
OK, but how does it work?
Have you ever heard the term: socio-technical system? In simple terms, even if we act within a purely technical environment, the products we create depend heavily on human factors - both individual and group - of those who create them. Separating technology from people is simply wrong. Both of these elements are a single system, whether we like it or not. A system that, in our case, creates an IT system. This is where an additional problem appears. While in the classical manufacturing systems (such as car production), the result is a tangible product, in the case of computer science, the system produces an information processing system and needs to process information for this goal. It might sound a bit complicated, but it’s a fact. Perhaps this is why computer science is so expensive and so difficult. What is the main information-processing organ that exists in nature? That’s right, it is the brain. The faster our brain adapts itself and our whole organism to changing environmental conditions, the better it works. For some, this is actually the way to define intelligence. And this brings us closer to the main point. The socio-technical system that we work in has to work in the same way as the brain does, in order to process information effectively and respond swiftly to changing conditions of the environment created by customers, the market, etc. Hence the recent popularity of agile methodologies or lean practices that improve team adaptation. But what does this have to do with the mirroring hypothesis? Well, the mirroring hypothesis says that not only the system architecture should respond to the customers and the market’s needs; the structure of our organization, in which we produce these systems should too. That means that even with the best architects who design the most amazing and timeless solutions, we won’t be able to avoid the previously mentioned problems if we don´t build our teams and our whole organization in a way that will mirror our solutions. Not only architects are responsible for modern and effective solutions; everyone who influences the shape of our organization does. Managers, coaches, team leaders, as well as teams themselves. OK, but what practical conclusion are we to draw from that?
In practice
Let’s go back to our brain example. As you know, the brain is divided into areas responsible for different life functions and senses. There are also those central elements, where information is processed, as well as “platforms” that constitute the base for all superior processes. If we want to think of our organization as the brain, we need to divide it into independent teams in charge of creating a value stream within a group of business domains. It might happen that a given domain is so complex it will have to be permanently assigned to one team. Of course, the teams should not be too large, as they must build mental models that each team member will understand and share. Additionally, our organization needs a team (or teams) responsible for building a technological or hardware platform for those former teams. Another important team is the one that will enable and coordinate the work in every sector and guarantee fluent communication. The details depend on how we have designed a specific solution and what paths - more or less agile - we’ve chosen. To wrap up - the above assumptions are most effectively implemented by agile, full-stack teams of 7-9 people, with an effective scaling method. But that is a topic for a whole different article. What should we remember from today?
Awareness
If you work in an organization divided into areas or departments, you are condemned to create products that will mirror that structure. If two different departments work on similar things, they will come out with exactly the same products. In conclusion: the more rigid the structures, the harder it will be to implement new and unique solutions. On the other hand, if your organization allows for flexibility in structure creation, your goal should be to make sure that the organization structure is as similar to your system architecture as possible and as agile as your human brain. Even when that architecture is not entirely ready yet! There is still a lot we can learn from it while transforming our organization and the very process of its creation.
If you are interested in Conway’s law, we suggest the following readings: - “Team Topologies: Organizing Business and Technology Teams for Fast Flow” M. Pain, M.Skeleton
- “Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis “ A. MacCormack, J. Rusnak, C. Baldwin
- “Conway Law” M.Conway
- “Socio-technical Congruence in OSS Projects: Exploring Conway’s Law in FreeBSD” M.M. M. Syeed , I. Hammouda