Harnessing Conway’s Law to Create Better Custom Software

Peter Drucker’s famous quote “Culture eats strategy for breakfast”—essentially meaning that a company’s culture impacts its bottom line more than its business strategy does—has been repeatedly borne out in both research and real-world environments. A close cousin of this concept, Conway’s Law, can be applied more specifically to custom software development, and it may explain why you don’t have the software that you need. So what is Conway’s Law?

In 1967, computer scientist Melvin Conway made this observation: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

He illustrated this point with the example of two teams, each tasked with producing the same compiler. The team of five people produced a five-phase compiler, and the team of three people produced a three-phase compiler. The way the teams were organized directly affected the way the technology was structured.

Conway’s Law gained so much traction that it was later studied by Harvard Business School and renamed the “Mirroring Hypothesis.” The results were published in a paper entitled “Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis.” Their finding: “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.”

Loosely-coupled software architecture comes from a loosely-coupled organization. So different services that the organization depends on can be updated in production independently, on demand, without needing to wait on each other to deploy in a specific order. As the study shows, loosely-coupled architecture produces significantly more modular systems. Modular systems are easier to change and quicker to adapt to new demands than monolithic systems.

Therefore, the modularity of a system is an excellent metric for describing the quality of a software system. The Harvard study notes that its findings “have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.” So, if you want better, more modular software, it’s time to examine the structure and culture of your organization.

How you manage teams, how you structure them, and how you encourage communication all contribute to an environment that you (consciously or unconsciously) have designed. The software that your organization can produce will mirror this design. Tight, formal hierarchies produce monolithic code bases that are much more difficult to maintain and change as time passes. So how do you make Conway’s Law work for you instead of against you?

Think about hierarchy. 

If the hierarchical structure of your organization separates developers from designers and operations and inhibits intimate communication between these disciplines, your software will suffer.

Ask yourself the following: How do approvals happen? How does communication happen? Are team members collaborating only through change tracking systems and not talking to one another directly? Is there a strictly rigid multiphase review process for rolling out new changes to production? Is there a database person who must apply changes to the database schema separately before you can deploy new production code changes? Are groups separated to a degree that they do not collaborate or communicate well? 

If communication and collaboration are lacking, put people together, either physically or in an online group, and get them talking directly. Then when a new feature is delivered, all the needed code rolls out together. Think about the modes of communication you are structuring and strive for an inclusive playing field. 

Think about team structure. 

Small (fewer than twenty) teams are better. Cross-functional teams of five to ten are ideal. Amazon famously has the "two-pizza rule"—if you can’t feed the team with two pizzas, it’s too big.

But it’s not just numbers that matter. Diversity, safety, and independence are just as important. A monolithic organization has isolated teams for quality control, operations, and product development. Splitting these up into three to four cross-functional teams with representatives of each skill set and allowing them to work safely and independently will open the floodgates of innovation.

Consider the example of a team with the following: one designer, two developers, one operations tech, one database tech, and one marketing specialist. Not only would this team have significantly reduced communication overhead, but studies show that members would be better able to keep project context in mind, respond to change, and make decisions quickly. 

Think about communication and coordination. 

How does your team communicate? Is all the “talking” done in Jira tickets without any actual speaking? This will produce terrible software.

Removing restrictions on communication in the organization allows for greater knowledge sharing and a freer flow of ideas. Use a mono repository so that teams can see and learn from each other’s code. Examine the effort required to coordinate. Do team members work in different time zones? Avoid a strict company hour policy. Give them the flexibility to work during hours when they can maximize their communication with one another. Remove unnecessary bottlenecks such as putting in a ticket to request deployment to production. Trust your people and allow them to act so they will have a greater sense of ownership and engagement with their work. 

These principles of communication and coordination are a major component of the DevOps mindset. This cultural movement for high velocity software delivery is based on the experiences of the people shipping the software and is designed to support and encourage the health of an organization.  For example, CI/CD pipelines improve software delivery and are extremely useful for rapidly shipping software and removing and reducing unnecessary coordination.

DevOps is not one person or team; it is a way of thinking that serves all team members and sets the foundation for a loosely-coupled organization. This communication and coordination will then be mirrored in the software that is produced. 

Foster a safe and respectful environment.

For any of the concepts we’ve discussed thus far to actually work, there is a crucial environmental factor that must be met. That factor is psychological safety. When the culture of an organization is characterized by trust and respect, the social structure will encourage free and open communication, resulting in a technical structure that is flexible and adaptable.

Keep in mind that at a certain point, how we communicate is more important than what we communicate. A team that communicates with empathy doesn’t simply deliver information for information’s sake. Each member purposefully communicates with the goal of helping others make independent decisions. Being free to ask questions, disagree, express concerns, and point out flaws will enable your people to drive innovation more effectively. 

Don’t tolerate a jerk. If someone is undermining the psychological safety of the team via personal criticism, making people feel unsafe to express themselves, or acting like they are the final word or smartest person in the room, then team members will not bring their whole selves to that room. You will have missed an opportunity to access the full strength of your team, and innovation will be stymied.

So be human, show feelings, express yourself, and encourage others to do so as well. If your organization does not have psychological safety, you can’t create the communication patterns to make Conway’s Law work for you, and you can’t create the technical system that works for the organization.

Apply Conway’s Law.

When presented with new information on any topic, we have three choices: ignore, accept, or lean in.

Ignoring Conway’s Law won’t prevent you from developing custom software. It will prevent you from developing good custom software that can adapt to changing environments. Accepting the real-world impact of Conway’s Law and ensuring your architecture doesn’t clash with developers’ communication patterns will notably improve the speed and innovation of your team. But leaning into Conway’s Law and taking control of your end product by effecting structural changes at the beginning is one of the most effective ways to transform the quality of software you can produce. 

So think about the structure and culture of your organization—it matters. Create small, cross-functional teams that have the power to do their jobs smoothly, without encountering unnecessary roadblocks. Make sure your people are psychologically safe and can bring the full power of their diversity and experience to the table. Embrace the mental shift of making room for more focus on cultural practices, not just technical practices. It’s all part of the same system. 

If your problems are cultural, you will never fix them by focusing on technical issues. Using Conway’s Law artfully requires flexibility and responsiveness to feedback. The benefits, however, will long outlast the initial growing pains, and you will have positioned yourself to continually produce the best possible software for your organization’s purposes.