BEST PRACTICES

February 27, 2023

Unlocking Transformation Success With Conway’s Law

This article advocates using Conway’s Law as a tool for transformation projects. Well-aimed organizational changes can contribute to an improved IT architecture and, conversely, an externally stipulated IT architecture can be used to influence the organizational structure.

Defined in 1967, but just as valid today, Conway’s Law states that there is an inherent relationship and, therefore, dependency between an organization’s communication structure and the technical systems it designs and/or operates. In this article, we explore the principle behind Conway’s Law and its influence on leaders, architects, and managers involved in IT-related transformation initiatives or public cloud adoption.

A solid understanding of this concept is instrumental in analyzing, designing, or implementing IT transformation initiatives that target either the organization or its technical systems.

As by keeping Conway’s Law top of mind, leaders are poised to gain an outside-in perspective, can identify communication gaps within the organization, recognize related risks and leverage these insights to drive and cultivate the transformation of both the organization and the system.

Introduction

A while ago, I onboarded a large-scale transformation initiative that blueprinted the rollout of a domain-specific standard system. An adjustment of the target operating model (TOM) for the organization was part of the initiative, yet only some high-level principles had been defined. Also, the initiative’s story explaining the change was still in the works, and I had some trouble putting my finger on what this was all about – at first. I then came across a cartoon by comics agilé that was about Conway’s Law [1], and thanks to this reminder, the scale and vision of the transformation initiative suddenly became crystal clear. The project with its basic principles and somewhat mundane technical goals referring to cost efficiency evolved into an ambitious and thorough transformation project of the organization itself, which was supposed to work with the new standard software.

The story above might sound familiar. Stories that imply a kind of relationship between an organization and its technical systems are ubiquitous throughout the IT industry. Usually, these stories surface to a broader audience when the relationship has been ignored or has not been fully taken care of: a company introduces that one standard software but then struggles for years to digest it on an organizational and process level.

A company introduces a hyped new software but then leverages only a marginal percentage of the software’s full potential, because the organization refuses to adopt it properly.

Or other stories about the pitfalls that come when building a shiny new user-centric web frontend over a product-centric legacy backend.

All these narrations hint at Conway’s Law. In this article, we explore the concept and explain why transformation teams shouldn’t ignore it, but instead consider software rollouts and organizational changes as two sides of the same coin [2, 3].

Conway’s Finding

In 1967, Melvin E. Conway, a computer programmer, submitted a paper that introduced the following theory: “organizations that design systems, are constrained to produce designs, which are copies of the organization’s own communication structures” [4, 5]. Or rephrased: “the way an organization communicates internally, is mirrored by the system it builds”. A hierarchical organization tends to yield a hierarchical system, a network-based organization tends to yield a network-based system, and so on.

The term “systems” is broadly interpreted here. It applies to software systems, but also more generally to all sorts of technical systems. Conway’s Law affects the systems produced “in” as well as “for” organizations. Furthermore, the term “communication in an organization” refers to both process-bound communication flows with a formal communication structure and communication flows incited by social networks with an informal communication structure.

Despite its name, Conway’s theory is not a law in the strict sense. And Conway’s finding had not been adopted immediately, his first submission in 1967 was even rejected due to insufficient evidence. Yet, both the Massachusetts Institute of Technology (MIT) and the Harvard Business School (HBS) eventually published evidence, which supports that there is indeed correspondence between communication structures and system structures, albeit not causation. An equivalent yet more appropriate name may therefore be “mirroring hypothesis” [6].

Reciprocity: Conway vs Reverse Conway

Before we start reflecting on the impact of Conway’s Law on transformation initiatives, we also should address the lesser-known variant of Conway’s Law, the “Reverse Conway” or “Inverse Conway” [3, 7]. This variant has become more prominent in the last decade. Just as a correspondence can be reciprocal, a system and its built-in or expected communication flows can also affect the organization that is applying them. Because of the Reverse Conway, hyperbolically, replacing a system ought to be understood as an important change driver (or even disruptor) on the organizational structure working with or operating that system.

Nowadays, we might expect Conway’s Law and Reverse Conway to be commonplace among people involved in large-scale IT-related transformation initiatives. And indeed, we often see it contained in a body of knowledge or reflected in a design principle such as “process follows system”. The number of abandoned system replacement initiatives, on the other hand, might tell a different story.

It is, therefore, good practice to keep Conway’s Law in mind when engaging in an initiative that aims to change an organization or its technical systems.

A recent showcase to illustrate the lessons of Conway is the adoption of the public cloud. Experience shows that public cloud adoption should be understood as a business transformation journey and not only a technical endeavor. And indeed, from building new solutions to securely operating the public cloud to allocating a budget for a pay-as-you-go platform, the adoption process requires an organization to adjust its internal processes, controls, design and delivery approaches, performance measurements, and communication flows if the platform and the economics of the cloud are to be fully leveraged [8].

Furthermore, when evaluating the inherent differences in public cloud platforms, we might again consider Conway’s Law and think about the organizations that developed these systems:

How were they organized internally?
How did they envision the communication flows of companies adopting their products and platforms?
And what happens if we adapt to their communication flow structure by adopting their cloud platform?
What related conclusions can we draw from their other products?

So, Conway’s Law might introduce new dimensions to our evaluation when selecting a cloud platform.

Gaps and Consequences

In considering Conway’s Law, we can assess transformation risks based on a specific transformation initiative. There are two aspects to be examined:

First, understand the gaps between the communication flow structure caused by your target architecture or system and the target operating model (TOM) for the system itself. We look for differences in planned value chains, imposed separations and organizational handoffs, role concepts, decision ownership, responsibilities, and KPIs. Overall, we are on the lookout for potential points of friction, attrition, or even fractures that will lead to inefficiency and eventually failure of the organization and the system.
“From inefficiency to failure” outlines the range of consequences that result from these gaps in the design of the communication flows, which is the second aspect to consider.

After identifying the gaps and their potential consequences, we can apply standard risk management procedures and try to close or at least mitigate/compensate for these gaps, e.g., by adjusting the system (system follows process) or the organization (process follows system).

In some circumstances, we may look at a specific gap between the target architecture/system and the TOM/organization from a different perspective and accept (or even emphasize) it. If we do not address them, they are likely to become organizational friction points (or even conflicts) that we can use to force an organizational change (Reverse Conway) or a reflection on the design of the system (Conway’s Law). Exploiting a gap can be done explicitly or implicitly. Applying Reverse Conway, also known as the Inverse Conway maneuver, requires obviously a robust architecture/system capable of inducing the desired organizational change [9, 10].

Conclusion

Conway’s Law and Reverse Conway demonstrate the presence of a relationship between the communication flows within an organization building or working on a system and the communication flows of the system itself.

Leaders, architects, and managers involved in IT transformation initiatives should be aware and understand how they can leverage these insights to identify and address transformation risks and drive the transformation itself.

The actionable insights for IT transformation are:

When we are involved in IT redesign projects, we should be familiar with Conway’s Law and Reverse Conway. We should understand that systems, especially IT systems, in some way have an opinion about how to operate efficiently and what communication flows are intended within the organization.
We should understand the differences in the communication flow between the system we are implementing and our target operating model for that system. We should treat the gaps as risks (transformational or operational) or, in some circumstances, use them as drivers for desired organizational change.
Finally, we can use Conway’s Law to examine how successful digital companies build their software and platforms and what communication patterns they have established. We could apply these learnings to our digital journey toward a more agile, network-centric enterprise. We might even consider using an Inverse Conway maneuver to facilitate our journey.

Sources

Thomas Peter

Architecture, Generali Switzerland

Further Reading