Skip to main content

Definition of “Conway’s Law”

Conway’s Law is frequently used to justify certain organizational boundaries that have a significant effect on cognitive load, which is why we believe it is important to discuss. The definition can be found here: https://en.wikipedia.org/wiki/Conway%27s_law

Conway's Law Wikipedia

Conway's Law explains how the way an organization communicates can influence the systems it creates. Named after programmer Melvin Conway, it suggests that the design of a system often mirrors the communication patterns within an organization. Essentially, the way people interact and collaborate within a company affects how they design products or services.

However, the Wikipedia article and others overlook the full conclusion of the original paper—in other words, a potential direction in dealing with Conway’s Law. The original paper’s conclusion offers further insight:

”The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.

This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.

Ways must be found to reward design managers for keeping their organizations lean and flexible. There is a need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity. The development of such a philosophy promises to unearth basic questions about the value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence.” - Source: https://www.melconway.com/Home/Committees_Paper.html

Therefore, the paper is, in a way, incomplete, since it provides direction in solving the stated problem but not the solution itself. The paper shares in detail an observation of a problem to be solved. It is not meant to be a law. The term “Conway’s Law” came much later. This ambiguity and incompleteness has led to several contradicting interpretations over time. We simplify interpretations into the following two categories:

  • Conway’s Law is an unavoidable problem.

  • Conway’s Law is an undesirable result of organizational bias.

In addition to this ambiguity, which we will deeply explore in other chapters, the software world has changed significantly since 1967 when the paper was published. Today, we don’t require many technically specialized individuals to divide the work of creating and maintaining software products. Technology, tooling, and techniques have enabled us to shift away from low-level technical details to more complex and innovative ways of creating customer value. A single person today can achieve considerably more than was possible 10 years ago, let alone 60 years ago. And with the advent of genAI, this progress is likely speeding up.

Therefore, the problem of the past—when work had to be divided due to the limited ability to deal with complexity—is today on a very different scale. One developer today can maintain many components and millions of lines of code.

Since Conway’s Law states that software design will reflect an organization’s communication structure, it implies that a single individual or team(s) with shared ownership will create hugely coupled software. Researchers have found that loosely coupled organizations tend to create more modular products than tightly coupled ones, highlighting the impact of organizational design on technical outcomes (*) Therefore, indeed, individuals or teams that share ownership create coupled software more often, but they also decouple when needed. Teams that don’t share ownership create distributed or decoupled software by definition, whether that is a good design idea or not.

(*) MacCormack, A., Rusnak, J., & Baldwin, C. Y. (2006). Exploring the Duality between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis

Inverse Conway Maneuver​

The inverse Conway maneuver is a popular interpretation and solution to Conway’s Law and assumes that Conway’s Law is inevitable. It was coined and advised as a trial by ThoughtWorks in 2014, but this advice was discontinued about one year later. Nevertheless, this approach remains popular.

”Conway's Law asserts that organizations are constrained to produce application designs which are copies of their communication structures. This often leads to unintended friction points. The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture.” - source: https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuverok

Unfortunately, the inverse Conway maneuver is interpreted in different ways. The common (mis)interpretation is the assumed stability of the technical architecture and, therefore, the team’s structure, which corresponds to a pre-defined architecture. As is very clear from Conway’s Law and the inverse Conway maneuver, the flexibility or evolution of the desired architecture is a crucial aspect. In other words, the inverse Conway maneuver assumes the ability of an organization to change both organizational and architectural structure in a cost-effective manner, in line with evolving architectural views. However, that would be quite a challenge and have far-reaching (negative) consequences, which is why such an ability rarely, if ever, exists, especially in larger organizations. Subsequently, we will explore why it is so difficult to continually evolve organizational and architectural structures toward desired states.