Unpacking Conway’s Law

I’ve been thinking a lot recently about organizational structure and design1. Eventually, I’m reminded and inevitably return to Conway’s Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Essentially, software companies will ship their organization; the boundaries and limitations in their product portfolios will reflect how its teams are internally organized. It follows, then, that a manager can take advantage of this interdependence by inverting the cause and effect, and drive their team structure towards their desired system architecture: the Inverse Conway Maneuver.

On its face, the law itself is a pretty simple social observation—for engineers of systems X and Y to define an interface with one another, they would need to communicate. It just so happens, though, that many of the attributes and behaviors and parameters that define the modern corporate hierarchy—the collection of expectations and responsibilities that encompass “reporting into” a manager—is congruent with these lines of communication. That is, the same phenomenon that is applicable to a pair of systems and engineers, can be recursively applied to incrementally more complex webs of systems and teams of engineers. Hence, an organization’s structure defines its architecture, which defines what it ships.

That’s not to say that a singular outcome is ever possible with any given org structure. With explicit effort, it’s possible to create communication architectures that run counter to normal managerial reporting structures; famous examples include the Spotify tribes model, the two-pizza-sized goal-driven pods model, and project/people orthogonal matrix management. And while advocates will swiftly highlight the benefits of such setups—typically pertaining to newfound development Agility™—there are costs to consider as well. Some common tradeoffs: additional management overhead, lack of long-term system ownership, duplicative efforts, divergence of product and technical quality. Overcoming these issues can require, well, additional teams and systems and processes.

Things get interesting when trying to apply Conway’s law at larger scales. Indeed, one of the most common moves a newly-hired executive makes upon taking over their new team is execute a team reorg2; veterans of such situations have learned to both expect and dread these moves. As a direct implementation of the aforementioned Inverse Conway Maneuver, the idea of defining an ideal system state and nudging a team in the right direction doesn’t seem too bad on paper.

Ask those new exec reorg veterans why it’s a bad idea, and they’ll likely cite the lack of context as a reason. If the end result is truly a more ideal state, the main problem is that it has to be transitioned from its current, presumably much coarser state embodied by real people and running systems that themselves have histories and relationships and previously-defined interfaces. That is, the “right” org structure cannot exist in a vacuum—it has to be populated and mapped back to the existing team, imperfectly.

The larger the scale, the more those imperfections act as constraints on possible organization transitions. Bigger teams have more specialized roles, some of which may be irrelevant or duplicative in the new org. New org charts usually uncover holes in management, which sometimes can be filled with existing folks laterally but otherwise leave teams running headless for a while. The politics of perceived and actual promotions and demotions rears its ugly head, and it’s particularly difficult with bigger teams to even anticipate where those friction points would materialize. Managing reorg retention and attrition is its own discipline.

Given all that, I wouldn’t blame anybody who looks at the complexity and cost of organizations and their structures and concludes, cynically, that it all seems completely unnecessary.

And they’d be right, in an environment where all of the externalities stay static. If the business and product can stay largely the same, the developers themselves3 and their teams can stay the same, and—to invoke Conway’s law—the development methodologies and systems and services can stay the same, then messing with how people are organized is incredibly disruptive for limited benefit. For the rest of us, we’ll just have to learn to get better at figuring it out.