Over fifty years ago, a mathematician and programmer named Dr. Melvin Conway stated in a paper submitted to the Harvard Business Review that
“[o]rganizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
This hypothesis eventually became known as Conway’s Law. The theory behind this law is based on the logic that effective, functional software requires frequent communication between stakeholders while eventually assuming that the structure of a system will reflect the social boundaries and conditions of the organization that created it.
Conway’s Law in Action
A good example of Conway’s Law was found in 1999 by UX expert Nigel Bevan as he studied corporate website designs. Bevan found that end-users often became frustrated with company websites because they were slow and difficult to use as the navigation, page design, and content structure often mirrored the internal concerns of an organization—instead of meeting the needs of the intended user first.
Another way to think of Conway’s Law is to look at a product constructed by four different teams. In the end, it’s likely to have four different parts supporting each team that designed their own section. This is why an open-source operating system like Android can be built by people all over the globe and is much more flexible, yet also much messier, than closed systems like iOS designed to work seamlessly within itself, but not with others.
In a similar analysis of open-source and proprietary closed-source software performed by the Harvard Business School in 2008, researchers revealed “significant differences in modularity, consistent with a view that distributed teams tend to develop more modular products”. This reinforces Conway’s initial thought in that:
- Organizational distribution and product modularity are correlated.
- Products really do end up looking like the teams that create them.
Greater Implications
Because Conway specifically refers to the communication structures of an organization being reflected in the end product of its overall system build, it’s also important to understand that he stated this observation in the late 1960s during the era of mainframe computing.
Today’s world is filled with modern tech designers who are building and designing new things in their own image every day. Some worry that because many tech companies suffer from a lack of diversity, Conway’s theory will take on greater implications if this lack of diversity means designers are subtly and inadvertently programming their own cognitive biases into their systems.
Leveraging Conway’s Law
Now that there is a greater understanding of these correlations between the communication structure of an organization and the software they create, new structures are emerging to achieve an outcome more aligned with the overall business model. The widely accepted solution to Conway’s law is to create smaller teams focused around single projects so they can:
- Iterate rapidly
- Deliver creative solutions
- Respond with agility to customer needs as they change
The thought is that smaller teams work more effectively while producing better results and bigger groups become less cohesive and more dysfunctional.
In the case of Netflix and Amazon, both utilize multiple small teams responsible for delivering small parts of the overall system. Each independent team can own the entire service they create from beginning to end which allows them to evolve and deliver changes to production faster.
If larger teams were adopted instead, then they would produce larger monolithic systems that could hinder experimentation and prevent delivering streamlined and efficient change with creative solutions.
Enter the Microservices Architecture
By loosely agreed-upon definition, microservices is an architectural style that structures an application as a collection of services that are:
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities
- Owned by a small team
The microservice architecture enables the rapid, frequent, and reliable delivery of large, complex applications. This method of development benefits from reversing the original logic of Conway’s Law by structuring a system into independent, self-contained services, so that teams can work independently. Sometimes this reasoning is referred to as “Reverse Conway’s Law”.
Microservices architectures aim to increase velocity, so they apply Conway’s law in reverse to structure the system to achieve this goal. However, if teams are set to gain or lose from a specific system structure, they can be tempted to invent architecture concepts to boost the size or power of their teams: whole new system layers can be conceived to justify headcount for a team and extend the scope of their team’s influence.
Herein lies the abuse of the Reverse Conway’s Law in that one could go as far as stating that if a party has the potential to gain something as a result of an architecture decision, then there is a greater potential of getting a politically motivated decision instead of an architecture decision.
Cons of Conway’s Law
Companies of all sizes and in all sectors have utilized and seen success from adopting Conway’s Law and started utilizing small agile teams in their system designs, However, at the same time, this concept is also earning its own detractors.
A Forbes article from 2017 noted there are potential drawbacks to letting Conway’s law guide the structure of your organization. The thinking goes that:
“Once you entrench small teams in this way, their respect and loyalty for that team often comes to outweigh their allegiance to the organization as a whole… Teams in disparate locations end up forming strong but exclusive identities as individual departments.”
It’s good for teams to form strong bonds, but those bonds should not become exclusionary and cliquish; otherwise, the organization loses its internal cohesion.
As with most things, the answer to designing a team is not as clear cut as applying a popular observation made over 5 decades ago. There are businesses that have stretched the boundaries of what is possible by using small independent teams to create fast-paced changes, but even these smaller teams can still suffer from their own internal neurosis and communication challenges.
Once things like insecurity, distrust, and fear start creeping into the mindset of a team, it’s Conway’s law that reminds us these same traits will seep into the systems these teams create. Once this happens we have to get these negative characteristics under control by embracing proper communication within a team or organization while also encouraging others to do so no matter how a team is scaled.
