NOTE

Conway's Law

#software-engineering (38)#teams (8)

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

(Melvin Conway)

Fred Brooks later gave it the name Conway’s Law in The Mythical Man-Month.

Early in my career, I worked at a software company that had 200 engineers spread across a single floor in a large building. By chance, last year I moved into the same neighborhood as the head of engineering at that company. I learned from him that since their IPO they had split their engineering org between local engineers and an overseas group. They saved lots on paper for a few years, and now their biggest technical challenge is the communication between teams, which bled into the architecture and has even influenced the quality and boundaries of products they build. Their org structure changed the product.

Martin Fowler’s note on Conway’s Law treats the law as a design input. You either accept the coupling between org communication and system structure or you spend the project fighting it.

The lesson here is to be intentional about org design. Small groups with rich informal communication tend to ship cohesive surfaces. When you split work across locations or time zones, assume interfaces will be thicker and interactions fewer.

Some teams run an inverse Conway maneuver on purpose. They change team boundaries and ownership to pull the architecture they want within reach. That only works when you treat org moves as seriously as schema changes. Re-slicing teams without changing incentives, backlogs, and measures of success relocates the friction without removing it.