Applying Conway’s Law: Navigating the Build vs. Buy Dilemma
Improve decision-making by using Conway’s Law
Improve decision-making by using Conway’s Law
Key Takeaways
Conway’s Law and the Inverse Conway Maneuver explain the correlation between organizational structure and software design.
We should consider the strategic value of a product when deciding whether to build to buy it.
We should acknowledge Conway’s law’s effect and internal communication cost when deciding to build in-house.
Introduction
As someone responsible for infrastructure and enabling products, one of my dilemmas is buying 3rd party tools vs. building in-house. While purchasing tools results in short-term costs (contract, legal, integration), in-house solutions come with long-term costs (development, maintenance, improvements).
To help in this decision, I take inspiration from the Inverse Conway Manoeuvre. In this post, I will share Conway’s law, the Inverse Conway Manoeuvre, and how to apply it when deciding on build vs. buy.
Conway Law
Fred Brooks coined the term in his book “The Mythical Man-Month,” following Mel Conway's paper from 1968:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Let’s take an example from an average tech company. Suppose the Marketing department manages the content, messaging, and branding while the Product department manages the functionality and the product itself. In that case, it usually results in separate marketing and product sites.
Why? If the two departments work in silos, each with its own goals, they can’t effectively work on the same software. For that reason, the software design is copied, it at least inherits, from the organizational structure.
Inverse Conway Maneuver
To proactively take advantage of Conway’s Law, Jonny LeRoy, and Matt Simons published a paper in 2010 offering a unique view. The maneuver suggests structuring the organization and teams to promote the desired system architecture.
Taking the example above, we should combine the Marketing and Product teams to have one site with consistent messaging and flawless user experience. By doing so, the resulting software will be one site that enforces the usage of shared components and reduce silos.
I must note the change is temporary. Without proper implementation, it will increase friction and impact execution. The right way to do so is by taking small steps and adjusting the software AND the organizational structure to achieve the desired goals.
Build vs. Buy
Let’s take a closer look at two examples to express how the ideas above can help in this decision.
Example A — an early-stage startup wants to add a more intelligent authentication solution, including login, SSO, and user management.
Example B — Alibaba decided in 2004 to launch its payment platform (Alipay).
Generally speaking, adding a 3rd party tool will increase silos as external stakeholders will work against it and not internally with Product teams. On the contrary, building an in-house solution requires extra communication and involvement from internal teams.
When analyzing these decisions, I ask myself -
Does the area in question bring innovative value to the table?
Does it worth spending the overhead of internal communication on its evolvement?
Assuming the early-stage startup doesn’t deal with security and sensitive data, it doesn’t require an innovative authentication solution. It also doesn’t require internal communication as it’s not its core proposition.
As for Alibaba, utilizing its retail network and disrupting the financial services in China was a critical strategic decision (increase revenue, offer financial assistance, reduce costs, and increase margins). It went as far as to create a separate business entity (IPO’d in 2020, set to be valued at around $300 Billion). Building such a solution in-house and connecting internal teams to work on it made sense.
Summary
In summary, by considering Conway’s Law and the Inverse Conway Manoeuvre, we can make informed decisions on whether to build or buy software, considering the desired system architecture, collaboration needs, innovation value, and strategic significance of the solution.