It is one of the universal rules that every product manager knows by heart:
“Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations… The larger an organization is, the less flexibility it has and the more pronounced the phenomenon.”
Dr Melvin Conway has first stated this law in the late 60s after an experiment in developing compilers with a group of people. For product development, the law means nothing less than: the way your teams and departments are structured will be mirrored in the way your product and its architecture works. If you have small, cross-functional and self-organized teams, a modular product platform or microservice architecture could be the result. If you have structured your teams around value streams, the things you build will operate around these value streams.
Over the past years, I often used Conway’s Law for describing and changing organizational structures to build better products. But looking back at that time and being in a more extensive transformation program for the past year, a question repeatedly came to my mind: Does Conway’s Law only work in one direction?
The reciprocity of Conway‘s Law
What do I mean by that question? It is pretty straightforward. Is the product only a result of the organization and its structure? Or does the product also influence the way the organization is structured? Does Conway‘s Law also work the other way around?
My personal experience is: yes, at least partly.
Evidence for the reciprocity of Conway’s law
I did not conduct any scientific experiments on this, but there are a few observations that support reciprocity.
#1 Product Strategies are developed without organizational boundaries
A good product strategy is never bound to the current organizational environment you are operating in. A strategy is aiming to create a future, and this future can look different from the current world. It is derived from a vision and not from the way the world works now. Together with the second observation, this will give Conway‘s Law another angle.
#2 Teams tend to find new organizational solutions on their own
Give product development teams a specific challenge, and they will find a solution. The same is true if you give product developments teams a product strategy that cannot be realized with the current organizational setup. In my experience, teams are pretty much aware of the boundaries that the organization and the team structures are giving them for developing software. And that will lead to challenging the status quo and finding better structures to build the products.
#3 A product changes the way the user is working
And here comes evidence number three. As we all know, products are intended to work in a specific way. So, our products change the way the user is working. And if you look at this for products that are developed for internal users like developing an e-commerce system for shop managers or a CMS for editorial users. Such an internal product can massively change the way the organization and its processes are structured. An example: You want to have a global system that every one of your users can work with and collaborate in? Building such a solution will help form a more global approach in the organization as well. Why? First, because product managers are talking to all those users and, by that, they are accelerating knowledge exchange. And second, because a product with a global capability in mind and corresponding features will enable and support global operations and change the organization by that.
But what is the real cause of this change
Looking at the circumstantial evidence, we cannot close the case. But we can form a hypothesis: The design of the systems an organization is creating will be reflected in the structure of the organization as well. An amendment to Conway‘s Law.
The design of the systems an organization is creating will be reflected in the structure of the organization as well.
But… Yeah, there is always a ‘but‘. The questions that are still on my mind: What about the time dimension? What is the real cause: Structure or Product? The classical chicken and egg problem.
Looking at my evidence above, you can argue that the development of a product strategy in itself is the first step in organizational change. It is a measure to develop the product and change the organization. It is not the result of the system, but a stimulus to change the system. It is the first step to develop the organization into building better products.
Taking this into account, I will not alter my hypothesis. But I will add a hypothesis: The product or product management in general is one of the major influencing factors in shaping organizational development and organizational transformation.
The product or product management in general is one of the major influencing factors in shaping organizational development and organizational transformation.
3 Steps to apply the Insights
#1 Develop a compelling vision of the future
A basis for every good product is a convincing vision for the company, and for the future, you are aiming to build. Make sure that you are not limiting your vision due to the current organizational boundaries.
#2 Derive a matching product strategy
Your product strategy should match your vision and, like the vision, should not be limited to the status quo. Don‘t let current structures be a boundary for your product strategy. If your product strategy requires radical change, then you should be aiming for that.
#3 Define principles that you want the product development department to follow
Based on your product strategy, derive a set of guiding principles for product development. Principles that the teams can follow. Principles that enable the teams to find structures that help to bring your product strategy to live.
What are your experiences with Conway’s Law?