Melvin Conway is a programmer and computer scientist who has made a lot of important contributions to the world of software. Among them is an often repeated phrase amongst people who spend their time “optimizing” things:

“Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.”

Conway said this in 1967 for a piece called “How Do Committees Invent?” and since then, software has eaten the world and “organizations who design systems” are at the nation-state scale of power. So, I think it’s important for a broader audience to be exposed to this idea and the implications of it.

First, what is an organization that designs a system? Well, the easy part is defining an organization: a group of people organized in the name of a specific goal or purpose. This could be a business, a nonprofit, a government, etc. The more interesting bit is the type of organization, one that designs a system. What is designing a system? In Conway’s words, “that kind of intellectual activity which creates a whole from its diverse parts may be called the design of a system.” As you can imagine, a definition this broad means that this category can include organizations that do everything ranging from weapons development, strategy consulting, or software development.

 

• Google? Organization that designs systems

• United Nations? Organization that designs systems

• Lockheed Martin? Organization that designs systems

• Your local electrician? Yep, that’s right, still an organization that designs systems

Conway’s observations seem especially prescient and relevant because in the 60 years since he wrote his piece, our world has become extremely dominated by organizations that design systems. That’s the nature of an information economy. Our modern society is filled with email jobs, and what are these if not just different roles taking part in organizations that design systems. We exist within these organizations and are actively shaping (and being shaped) by them. So, uh, understanding the dynamics of this relationship seems critical.

With that in mind, what is the constraint that Conway observes in these organizations? It’s essentially the idea that “you ship your org chart.” If your startup works in small, distributed, modular teams….you will probably ship modular and distributed software. On the other hand, if you're a physical manufacturer with siloed, alienated divisions, your product will inevitably reflect this fragmentation. What should be a cohesive whole becomes a collection of disparate pieces. You can see examples of this everywhere once you get introduced to the concept:

Source: Manu Cornet / Goomics

• Why does it feel like Microsoft’s different products are…somehow competing against each other instead of complementing each other? Conway’s Law

• Why are Apple’s products so successful at keeping you in their walled garden? Conway’s Law

• Why does it feel like Google has 5 different versions of a product that all do the same thing but end up getting chopped with no warning? Conway’s Law

• How did Amazon create AWS and its universe of cloud services? Conway’s Law

I’ll pick on that last example in a bit more detail. There’s the famous “two pizza” team rule that Jeff Bezos installed at Amazon and AWS (“teams must be small enough to able to be fed by two pizzas”). Everyone always focuses on the small team size part of that, but the real difference maker was his other edict: his API mandate. Basically, the birth of AWS essentially came from a shift in the communication structure between these two pizza teams. They were expected to work in independent and decentralized teams that would communicate with each other through a mutually agreed universal data structure. This translated to each team owning a specific function & service that would communicate with another team’s service as APIs. These team-to-team API communications became the very infrastructure products—modular, independently scalable web services—that now power much of the digital world.

“Invert, always invert: Turn a situation or problem upside down. Look at it backward.” - Charlie Munger, Poor Charlie’s Almanack

Why does this matter outside of being a fun game to play?

Basically, if you don’t actively recognize this phenomenon, your organization and your product(s) are all liable to suffer technical challenges from human obstacles. On the other hand, if you can recognize this idea before you begin any sort of system design (aka build your product), you can use it to your advantage. You can invert it. Rather than allowing team structure to dictate development, design your organizational communication to support your technical & product goals. You’re at an early stage in your org’s life cycle and constantly pivoting? Well, that means that your software needs to be modular, agile, and adaptable. If we follow the idea behind Conway’s Law, then that means we should set up our development teams to be small & multi-disciplinary, with very fast communication feedback loops and decision-making from a bottoms up perspective. This way, you are anticipating that your organizational structure will bleed into your product and positioning yourself to take advantage of it.

Let’s consider a vastly different situation, since every example out there these days is about building “modern agile systems” and breaking down silo’s and all the build fast ideas. What if your organization has a deep history and legacy, with the corresponding baggage and debt that comes with. Let’s also say that your organization is in a heavily regulated space, where there are steep consequences to failures in compliance. Something like, healthcare or insurance. The real important stuff. If you are designing a system in this scenario, you are not going to be optimizing for the same things as the early stage example. Instead, you might consider optimizing for security, reliability, and deliberate communication loops, making sure to minimize the chances of failure and being very conscious of risk. With that framing, you may instead build larger, centralized teams with explicit & stringent communication processes, purposeful information flow, and actually silo more areas away from each other. Compliance tends to be more difficult when there’s a constellation of decentralized autonomous teams. Information just flows in different ways.

One final point to consider is that while Conway's Law provides a powerful lens for organizational design, implementation isn't frictionless. Restructuring teams isn't merely a technical decision—it involves navigating established power dynamics, cultural resistance, and individual career concerns. Leveraging Conway's Law requires just as much attention to human psychology as it does to system architecture. The technical artifacts we create inevitably embody our social structures, complete with their strengths and pathologies. In the end, the core idea is not one silver bullet way of organizing your people to build better systems. Instead, the real value is inverting Conway’s Law:

• Reflect deeply on your unique context and scenario

• Recognize and anticipate these effects

• With that knowledge in mind, design your organization in the manner that you want or need your system to work

• As opposed to blindly adopting fashionable organizational frameworks (squads! scrum! SAFe!) and hoping your system will somehow transcend your communication patterns. The methodology matters far less than intentionally aligning your organizational design with your desired system architecture.

Full credit to the Conway himself and Manu Corbet for his legendary comic:

• http://melconway.com/research/committees.html
• https://goomics.net/62