Take a good look at your product. Then take a look at how your organization is built. Next, let’s take another look at your product. Do you see any parallels?
Chances are, your product and your organizational structure are similar. More specifically, there’s a good chance your product mirrors your company’s communication structure. That was the case in 1967, and it still is.
Conway’s Law
To quote the author:
“Any organization that designs a system (the term here is broader than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”
Melvin E. Conway, How Do Committees Invent?
In the words of Melvin E. Conway, if your product team is divided into smaller groups working on different parts of the system, the resulting software is likely to be made up of smaller parts that work independently of each other and communicate with each other in the same way that the smaller groups within the larger team did.
In short, the way a team works together has a much greater impact on the final product than most of us think. Conway’s Law is one of the many reasons why large companies stumble and fail when introducing new technologies that require different organizational structures.
Why is this the case?
- As a company grows, developing a product means developing the processes and structures behind the product. Simply putting together a design team means that certain design decisions have already been made.
- The human brain is designed to conserve energy by following clearly defined rules and avoiding unnecessary hazards. Therefore, we tend to break difficult problems into smaller, more manageable pieces. When teams are divided by function, each group tends to focus on improving its own part of the system rather than improving the system as a whole. These limitations are often reflected in the finished software.
- Organizational cultures that emphasize hierarchy and control tend to result in less flexible communication systems and thus more rigid software architectures. As a result, the product management culture and the product itself can be influenced by the prevailing values of the organization.
- Cultures that emphasize OKRs tend to favor structured activities (low variability and uncertainty) over open-ended challenges, even if that culture values learning and experimentation. This makes the already difficult path of developing and adopting new technologies even more challenging.
What can you do to avoid this?
- assemble your teams to best support the structure you envision for the software you’re developing;
- make sure that your product is based on the mental models of your users, not on those of your company or your team members;
- extend your company’s mental model for collaboration itself. To get started, I recommend https://teamtopologies.com/;
- always encourage collaboration between teams
