Conway's Law

That's the way computer scientist Melvin Conway put it in a 1968 paper titled “How Do Committees Invent?” His point was that the choices we make before we start designing any system most often fundamentally shape the final output. Or, as he put it, “the very act of organizing a design team means that certain design decisions have already been made.”

There's an etymological resonance here worth noting. The word “design” comes from the Latin designare—to mark out, to point out, to devise. Conway's insight is that organizing a team is a design act. You mark out the boundaries before anyone draws a line.

Conway cited a few key inspirations: John Kenneth Galbraith and historian C. Northcote Parkinson, whose 1957 book Parkinson's Law and Other Studies in Administration spelled out the ever-increasing complexity that any bureaucratic organization will create. Judging by the focus on modularity in Conway's writing, he was also clearly influenced by Herbert Simon's work on the architecture of complexity.

Very few have the chutzpah to actually name a law after themselves and Conway wasn't responsible for it. The naming came a few months after the “Committees” article from a fellow computer scientist named George Mealy. In his paper for the July 1968 National Symposium on Modular Programming (which I seem to be one of the very few people to have actually tracked down), Mealy examined four bits of “conventional wisdom” surrounding software development at the time. Number four came directly from Conway: “Systems resemble the organizations that produced them.”

While most people—including Conway on his own website—credit Fred Brooks' 1975 Mythical Man Month with naming the law, it seems Mealy deserves the credit. Though Brooks' book is surely the reason so many know about Conway's important concept.

As an aside, it's hard not to think that Mealy's third point—“if one programmer can do it in one year, two programmers can do it in two years”—sounds a lot like Brooks' mythical man month concept. Mealy worked with Brooks on OS/360 and in the book Computer Pioneersby J.A.N. Lee it's mentioned that Mealy's Law was also named at the same 1968 symposium: “There is an incremental programmer who, when added to a project, consumes more resources than are made available.”

Why does this happen? The answer starts with some basics of hierarchy and modularity that Herbert Simon offered in his Parable of Two Watchmakers: breaking a system down into modular subsystems seems to be the most efficient approach in both nature and organizations. We see companies made up of teams which are made up of more teams and so on. But that still doesn't answer why they tend to design systems in their own image.

For that we turn to the more recent research around the “mirroring hypothesis.” Carliss Baldwin, a professor at Harvard Business School, has been spearheading much of this work. Her 2016 paper with Lyra Colfer is a treasure trove. Their theory:

In other words, as long as people need to work together on problems, it makes decent sense for the solutions to resemble the teams responsible. The argument is that a mirrored product is both reasonably optimal from a design perspective (since organizations are structured with hierarchy and modularity) and cuts down cognitive load by making it easy for everyone to understand—because it works like an org they already know.

The paper surveyed research to understand where mirroring shows up and the answer is: everywhere. They found evidence across expected places like software and semiconductors, but also automotive, defense, sports, banking, and construction. For what it's worth, I've seen it across industries in marketing projects throughout my own career. Your website nav is just the most visible symptom.

There's something related worth flagging here: the role of information hidingin pushing companies into Conway's Law. Companies naturally hide information within teams for the sake of simplicity elsewhere. Finance doesn't expose the detailed rules of GAAP accounting—they distribute a monthly report. This information hiding is a feature, not a bug, but it reinforces the mirror. Each team becomes a black box to every other team, and the system they collectively build reflects those boundaries.

So what can organizations do about Conway's Law? There seem to be three approaches.

Option one: do nothing.It may well be the best way to design a system for that organization and problem. If your org structure happens to be well-suited to the system you're building, the mirror is working for you.

Option two: find an appropriate balance.If you buy the idea that some part of mirroring is about making it easier to understand and maintain systems, it's probably good to keep some of it. But it doesn't need to be all or nothing. Baldwin and her co-authors have a framework for thinking about different approaches to mirroring depending on the kind of business and its competitive environment.

Option three: strategic mirror-breaking.This is also called an “inverse Conway maneuver” in software engineering circles. You outline the system design you want—usually something more modular—and back into an org structure that looks like that. Design first, re-org second.

The inverse Conway maneuver deserves its own section because it's the most actionable response to Conway's Law—and the one most organizations get wrong.

The idea is simple: if your system architecture inevitably mirrors your org structure, then to get the architecture you want, you should change your org structure first. Most companies do the opposite. They draw the system they want on a whiteboard, hand it to the existing teams, and wonder why the result looks nothing like the diagram. It looks like the org chart. It always does.

Sam Newman at ThoughtWorks put it well: the inverse Conway maneuver means evolving your team and organizational structure to promote your desired architecture. Your goal is to make it easy for the right people to communicate—and equally important, to make it unnecessary for the wrong people to coordinate.

In practice, this often means smaller, more autonomous teams. Amazon's two-pizza teams. Spotify's squads. The principle is the same: if you want loosely coupled services, you need loosely coupled teams. If you want a tightly integrated product, you need people who talk to each other constantly. The architecture you get is the architecture your communication patterns allow.

It's a bit like the famous observation—often attributed to Churchill—that “we shape our buildings and afterwards our buildings shape us.” Or as John M. Culkin put it about media: “We shape our tools and thereafter our tools shape us.” Companies organize themselves and in turn design systems that mirror those organizations, which in turn further solidify the structure that was first put in place. The inverse Conway maneuver tries to break that cycle deliberately.

In case this all seems academic, the architecture of organizations has been shown to have a fundamental impact on a company's ability to innovate. Tim Harford wrote a piece for the Financial Times that heavily quotes a 1990 paper by economist Rebecca Henderson titled “Architectural Innovation”. The paper describes the kind of innovation that keeps the shape of the previous generation's product but completely rewires it: think film cameras to digital, or the Walkman to MP3 players.

A case study co-authored by Henderson describes IBM's PC division as “smothered by support from the parent company.” The PC business was eventually sold to Lenovo. What had flummoxed IBM was not the pace of technological change—it had long coped with that—but the fact that its old organizational structures had ceased to be an advantage.

This is where Conway's Law meets AI strategy. The companies that struggle most with AI adoption aren't the ones with bad technology—they're the ones whose organizational structure was optimized for a different era of technology. Their teams, approval chains, and vendor relationships were designed for the SaaS world. And per Conway's Law, the AI systems they try to build will mirror that structure—siloed, vendor-dependent, designed around procurement rather than capability.

The inverse Conway maneuver for AI looks like forward-deployed engineering: collapsing the layers between technical capability and business context. Instead of a chain of consultants, PMs, and vendors each adding their own communication overhead, you put the engineer in the room with the people who have the problem. The system you build reflects that directness.