How Conways Law Influences Software Development

Melvin Conway was a computer programming pioneer and hacker. In 1967, he defined the relationship between systems and communication. “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

Nearly all system design and implementation rely on communication between multiple contributors, thus, the patterns of communication between these contributors is an often unnoticed factor determining project outcomes. If you asked most product owners to create a list of factors affecting their software development outcomes, you’d expect to see obvious factors like requirements, timeline, budget, talent, or technologies. Conway’s Law challenges us to expand our thinking and acknowledge that software often mirrors the communication structures of the organization that produced it.

“Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.”

The implications of Conway’s Law beg the question: “What if we were to spend as much time considering our project team’s communication structure as we do the project’s budget, requirements, and technologies?”

Does Conway’s Law Truly Operate as Theorized?

While Conway’s Law feels intuitive, anecdotal accounts of its operation are widely reported by software veterans. We only know of one reputable study attempting to validate its operation with empirical data across a large sample of projects. “Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis” was co-authored by faculty of Harvard and MIT and first published by Harvard Business School in 2007.

The authors introduce the concept:

A variety of academic studies argue that a relationship exists between the structure of an organization and the design of the products that this organization produces. Specifically, products tend to “mirror” the architectures of the organizations in which they are developed.

The authors set their hypothesis:

In this study, we provide evidence to support the hypothesis that a relationship exists between product and organizational designs. The experiment compared software products with similar purposes that were developed under different organizational structures: The software industry represents an ideal context within which to study these different organizational forms, given the wide variations in structure observed in this industry. At one extreme, we observe commercial software firms, which employ smaller, dedicated (i.e., full-time), collocated development teams to bring new products to the marketplace. These teams share explicit goals, have a closed membership structure, and rely on formal authority to govern their activities. At the other, we observe open source (or “free” software) communities, which rely on the contributions of large numbers of volunteer developers, who work in different organizations and in different locations (von Hippel and von Krogh, 2003).

In essence, the authors studied the differences between comparable software products developed by open-source collectives and those built by commercial software firms with a traditional hierarchy.

‍

“We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization. We measure modularity by capturing the level of coupling between a product’s components. The magnitude of the differences is substantial – up to a factor of eight, in terms of the potential for a design change in one component to propagate to others.”

This evidence offers proof of Conway's 1967 observation and the matching anecdotes of modern software teams: distributed teams with open and independent communication structures will produce modular and decentralized system architecture while consolidated teams within formal hierarchies tend to produce monolithic products with a centralized codebase and architecture.

Using Conway’s Law to Build Better Software

Conway’s Law tells us that our products are inevitably a mirror of our team’s communication structures. If you’re intentional about structuring your team, you’ll get the product you intend.

Consider your basic organizational structure

If the business needs a modular, rapidly-changing, and scalable product, it should organize teams to match. They should be distributed, informal, independent, and open. This is the ‘mission command’ model. This structure can be likened to the open-source software community.

On the other hand, if the business needs centralized, controlled, and monolithic systems, teams should be organized in a single formal hierarchy with a well-structured chain of command. This is the ‘command and control’ model. This structure is similar to proprietary and closed-source software team.

Build smaller multi-functional teams

If you’re aiming for an architecture of loosely-coupled services representing core business capabilities like invoicing, delivery, or inventory, try building smaller multi-functional teams which serve those business capabilities, rather than siloing teams into functional hierarchies like engineering, IT, QA, design, data, product management, or marketing. Multi-functional teams carry less communication overhead because most feature work revolves around business capabilities but cuts across functional boundaries. Multi-functional teams require less cross-team coordination per feature delivery. When a change or interruption occurs in one of these teams, the remaining teams are free to continue uninterrupted. Multi-functional teams are a perfect fit for organizations embracing microservices architecture.

Organize around your product’s core value

Identify the most important aspects of your product and align your teams accordingly. When your team’s communication structure is supportive of the product’s core values, it's easier to deliver software that meets user needs and drives business outcomes.

For example, if you need a large central database that supports many business capabilities, ensure your database and infrastructure engineers are communicating closely as a centralized team. If they were to be divided across separate teams, Conway’s Law tells us that our centralized database would soon give way to decentralizing forces.

Or, if your product is heavily localized across nations or regions, then it makes sense to decompose the organization into separate and autonomous multi-functional teams for each locale. In this case, a centralized team would fail to properly accommodate local requirements and produce an overly-generalized product.

Examples of Applying Conway’s Law

We’ve put together some examples that demonstrate how to observe Conway’s Law when organizing software teams.

<button-cta>Example #1 - A beautiful social mobile app.
Core values: User experience and interface.
The Conway-Friendly Team: Separate cross-functional development teams for iOS, Android, and Web. Each with a bespoke front-end optimized for a wonderful experience on every screen and shared back-end services.

Example #2 - An internal claims tracking system for an insurance company.
Core values: Cost-effective with cross-platform compatibility.
The Conway-Friendly Team: A centralized development team and single codebase serving all platforms.

Example #3 - An internet company that’s rapidly growing and frequently adding new features
Core values: An architecture which consists of many decoupled services, which can be worked on independently
The Conway-Friendly Team: Many small teams with intentionally formalized and constrained communication pathways, which lead to many small, loosely-coupled services.

Example #4 - A financial services firm
Core values: All loan products must be validated for compliance with various local, state, and national laws
The Conway-Friendly Team: A centralized Loan Products team, with embedded compliance experts.<button-cta>

Work to align your organizational boundaries in accordance with your system’s architectural boundaries. These boundaries will form the ‘paths of least resistance’ by which information flows during the course of the project. When these communication pathways are direct, efficient, and without excess overhead, collaboration is faster and easier. When communication structures are in conflict with system architecture, solutions become constrained and progress slowed. Over time, your architecture will evolve towards whatever communication structures you have in place - that’s Conway’s Law!

Conway’s Law Operates, Whether You See It or Not

Melvin Conway’s 1967 observation that software products mirror the communication structures of their human creators has since been validated by research published by Harvard Business School. Understanding Conway’s Law and its implications on system design and development help ensure organizations build the software they intended and avoid unnecessary pitfalls. Artful application of Conway’s Law leads to better collaboration, less communication overhead, and faster progress. And for these reasons, among others, we encourage practitioners to give serious consideration to the implications of Conway’s Law when building products and organizing teams.