Conway’s Law and Intentional Design

Written by

Sergio Caredda

Posted on

February 21, 2022

Edited on

September 10, 2024

The organisational value of Conway’s Law

The reality is that this statement has a much broader validity. In all my work in organisation design and beyond, the feeling that this law holds is a constant.

Scholars often refer to the law by two related concepts:

Homomorphism or Isomorphism (Kelly, 2006). I won’t discuss the difference in the two terms, but essentially is a mathematical principle by which one structure holds a structure-preserving map of another structure. In simpler terms, a system replicates recognisable elements of the organisation that developed it. This leads to what Allan Kelly (Kelly, 2014) defined as the Reverse of Conway’s law: Organisations with long-lived systems will adopt a structure modelled on the system.
In simpler terms, some (MacCormack et al., 2008) call it the Mirroring Effect, by which a system produces a mirror image of the organisation that made it.

For the moment, it is sufficient to say that multiple researchers have validated these principles in various fields, not just in software design.

But why is this important?

The reason is that if we move away from one second from software products into something broader, we can immediately see many relationships with concrete cases out there:

We have seen already how a massive aeroplane accident has resulted from a faulty communication structure in an organisation in theory designed to be entirely focused on safety and the importance of engineering.
Several large scandals in organisations (think of Enron) have resulted from conscious organisational decisions that ultimately reflected the failure of an entire system.
Think also of the minor everyday issue you might have with customer support for a product when you’re getting handed over from one department to another. Isn’t that the result of the internal organisation structure?

This is becoming more and more relevant today because the acceleration aspect of VUCA makes all these aspects more visible.

An example: Retail

Having had several experiences in retail, I see the actual effects of Conway’s Law whenever I enter a store. Physical stores (and, notably, e-commerce sites) deeply reflect how the organisation is structured and its communication structure. Think of apparel: few cases come immediately to mind.

Apparel stores are mainly organised across gender (men/women) differentiations and age clusters (kids/adults). In most cases, this reflects a distinction that runs deep into the organisation, from style to product development, to merchandising and sourcing. This distinction immediately creates issues the moment genderless fashion comes into play and limits blur: small sizes, another area grouped under “kids”, even if adults also buy them.
So-called “omnichannel” services. Ever tried to buy online and return something in store? I’m sure you all have experienced at least a pair of rolled eyes by the chair when asking for this service. The issue is that most organisations are still organised by channel; thus, returning to a physical store means that something sold online will end up in the stock count of a physical store. In most cases, business control mechanisms, resource allocation, incentives all are still by channel, despite the promise of an omnichannel experience.
I have already mentioned the example of customer support before. How often did it happen to have had a technical problem with a product you bought, and while seeking assistance, you get bumped from the retailer to the producer, from the customer service department to the technical one.

All these examples reflect how broad the implications of Conway’s Law are, especially if we intend the concept of “system” in its most enormous possible sense, precisely as Conway himself intended.

Key Implications of Conway’s Law.

Let’s see the key implications of this Law onto various domains impacting general management practices as well as organisation design.

1. System Design Reflects Organizational Structure.

The way a system is structured often mirrors the way teams within the organization are divided and how they communicate with each other. If an organization is divided into silos or teams that rarely collaborate, the system will likely consist of distinct, loosely integrated components. Conversely, if the organization fosters open communication and collaboration, the system may be more cohesive and well-integrated.

Example: If a company’s software development team is split into front-end and back-end teams, the resulting software system might have a clear separation between the user interface and the database logic, reflecting this organizational boundary.

2. Communication as a Limiting Factor.

Communication barriers within an organization can create challenges in building cohesive systems. Teams that don’t communicate well or are isolated from one another will struggle to integrate their work smoothly, resulting in systems that may not function as well as they could.

Example: In a large corporation, the marketing and IT departments may not collaborate effectively, leading to the development of a customer relationship management (CRM) system that does not fully align with marketing’s needs.

3. Influence on Software Modularity.

Conway’s Law highlights how organizational boundaries create natural divisions within a system’s architecture. These divisions often lead to modularity in system design, where different teams are responsible for different modules or components. This can be beneficial if done intentionally, but it can also result in unnecessary complexity if the organizational structure is not aligned with the system’s needs.

Example: A company with multiple geographically dispersed teams might develop software where each team is responsible for a different module or feature, leading to a modular system with distinct interfaces.

4. Organizational Change Impacts System Design.

When an organization undergoes structural changes—such as reorganizations, mergers, or acquisitions—its communication patterns change, and these shifts can impact the systems the organization produces. Systems designed under one organizational structure may struggle to adapt to a new structure without undergoing significant modifications.

Example: After a merger, two companies with different organizational structures and development practices may find that their systems are difficult to integrate, as they were designed under different communication and management frameworks.

5. Alignment of Teams and Architecture:

To produce high-quality systems, it’s essential that the team structures align with the desired architecture. Organizations should intentionally design their teams to reflect the structure of the system they wish to build, fostering good communication and integration where it’s most needed.

Example: A company building a microservices architecture should organize teams around each microservice to ensure clear ownership and responsibility. Each team can focus on building and maintaining a specific service, with clear communication channels for integrating those services into the larger system.

Application and Countermeasures.

Conway’s Law serves as a reminder that we need to approach Organisation Design in a holistic, strategic view. Working on one element of the organisation causes impacts on the other, whether we want it or now. Applying the principle of intentionality, we can however exploit Conway’s Law to foster emergent qualities of the system. Let’s see how with a few examples.

1. Agile and Cross-Functional Teams.

Agile methodologies, which promote cross-functional teams, are a direct response to Conway’s Law. By creating teams that include all the necessary skills—such as developers, testers, and designers—organizations can reduce the friction between different parts of the system. This ensures that the system is developed more cohesively, as the communication and structure within the team are more fluid.

Example: In an Agile environment, a team tasked with building a particular feature includes members from development, quality assurance, and user experience, ensuring that the feature is developed as an integrated whole rather than as disconnected parts.

2. DevOps and Continuous Integration.

DevOps practices, which seek to break down silos between development and operations, also aim to address the challenges highlighted by Conway’s Law. By fostering closer collaboration between these teams, organizations can build systems that are easier to deploy and maintain, reducing operational bottlenecks.

Example: In a DevOps model, developers and operations teams work closely from the start of a project to ensure that software is developed with deployment and infrastructure considerations in mind, leading to smoother releases and fewer post-deployment issues.

3. Microservices and Conway’s Law.

Microservices architecture, where systems are broken into smaller, independent services, is often cited as an architecture that matches Conway’s Law well. Organizations building microservices need to align their team structures with the services they are building to ensure autonomy and effective integration.

Example: A company adopting microservices might structure its teams so that each team owns a specific service end-to-end, from development to deployment, ensuring accountability and reducing dependencies between teams.

4. Organizational Restructuring

When organizations undergo restructuring, Conway’s Law suggests that the systems they manage may need to be redesigned as well. New communication patterns within the organization may demand changes in how systems are integrated or how responsibilities are distributed across teams.

Example: After a corporate merger, an organization might need to consolidate overlapping systems or redesign software that was built with a different team structure, in order to support the new organization’s goals and communication structure.

A possible corollary to Conway’s Law.

This is why we should look at the critical output that an organisation produces, the experience delivered to its customers. This makes me think we can extend Conway’s Law with a corollary.

The quality of customer experience delivered by an organisation will inevitably be the product of its organisational design.

And I intend all elements of organisational design. Communication structure is one (and probably the most relevant), but what emerges here is another layer of meaning for the concept of intentionality in organisation design: you want to provide consistency across all your organisational elements.

There are cases of organisations that have reviewed their design with this principle in mind (Gilson, 2021). But we need to be careful here. The idea to go by a shortcut by applying what is called Inverse Conway Maneuver solely to a part of your organisation framework can be equally dangerous if not done strategically (Durand, 2021). The example is for those organisations that started distributing teams in an area to discover how many political issues arose, with individual groups still guided by old-framed values of power linked to size (Woods, 2017).

Another call for Intentionality

A few years ago, in his book How Google Works, Eric Schmidt (Schmidt, 2014) casually referred to the outputs of Conway’s Law.

You should never be able to reverse engineer a company’s organizational chart from the design of its product.
Eric Schmidt, How Google Works.

I found d this quote to be illuminating back when I read it, exactly because of the load of consequences that Conway’s law brings with it. How often by buying a product, or experimenting a service, you are clearly able to see the defects of the organisation that produced it?

The above strikes a new chord for the Intentional Approach to Design that I am exploring and should include the following steps.

Adopt an outside-in perspective, understanding customers and critical stakeholders in your design. This means moving away from the idea that the environment is simply an external factor, moving entirely into an Ecosystem logic.
Always consider communication flows within the organisation as what will make or break your design. This means thinking both in terms of formal Organisational Model and Operating Model, but also in terms of the informal collaboration channels.
Make sure you understand your own bias as the organisation’s designer. This is the most challenging part because we often underestimate the role of our ideas and how much they influence the design.
Remember that Intentional Example will be the route for propagating the new design. As we discovered last week, it is paramount that change is implemented by intentionally giving the correct examples as needed.
Last but not least, make sure you intentionally decide which organisation components will not be designed and leave the emergence. Choosing not to choose is a critical element of Conway’s Law because the property to which the law refers is latent, not intentional.

A Loop of Continuous Intentionality

When I originally posted this article as part of my newsletter, I received quite a lot of feedback. Antonio di Stefano referred to the concept of Lemniscate, an algebraic figure where all the points of the curve have a consistent relationship with their focus. The resulting figure is akin to the symbol of infinite we often use.

Fig.2: Bernouill’s Leminscate

Why is this relevant? Essentially what this figure represents is that for any internal point there is an external representation of it. And vice-versa. So, for any intentional decision, we do on the design, there is an unintentional consequence externally, at the same time for any external situation that affects our organisation, there is an unintentional consequence internally.

The way we design (or chose not to design) the way we organise ourselves, generates images of us in all successive projections or systems. And everything that impacts from outside influences our design

This really makes Intentional Design an endless pursuit of consistency between intentional design action and external system of reference. With Conway’s Law being somewhat the engine of propagation, so deeply linked with consistency.

Conclusion

Conway’s Law suggests that the systems organisations build will reflect the communication structures within those organisations. This principle highlights the importance of aligning team structures and communication patterns with the system architecture to produce cohesive, well-integrated solutions. It applies broadly, from software development to organizational design, and is a powerful reminder that organisational structure and system design are deeply interconnected. It also serves as the best demonstration and support for the application of intentionality in Organisation Design. Finally, the proposal of a corollary to Conway’s Law suggests that other effects (such as Customer Service) can also be fully interpreted as linked to this law.

Have you seen Conway’s Law in action? What are your thoughts about it? Is it something we should exploit instead of battling?

The “Laws of Organisation Design” Collection. This article belongs to a series focused on the different principles and laws that govern organisational behaviours, decision-making and group work, and that should be taken into account in organisation design projects.

The Laws of Organisation Design