Conway's law

In 1967 a computer scientist named Melvin Conway wrote up an observation and sent it to Harvard Business Review. They rejected it on the grounds that he had not proved his thesis. He sent it instead to Datamation, a computing magazine of the day, which published it in April 1968 under the title How Do Committees Invent. The claim was simple and strange. Any organisation that designs a system will produce a design whose structure copies that organisation's own communication structure. Not as a metaphor, but literally. Four teams building a compiler will ship a compiler with four parts. A company where two departments barely speak will ship a product where two components barely connect. Fred Brooks cited the paper in The Mythical Man-Month and called it Conway's law, and the name stuck. Forty years after the rejection, researchers at Harvard Business School put it to the test, comparing software built by tightly coupled commercial firms against software of the same kind built by loosely coupled open source communities, and found the correspondence the law predicts.

Your customers are holding a physical copy of how your company communicates, and they experience it as friction. The org chart is worth separating from that, because the two are not the same thing. The chart is the version of the structure that somebody wrote down, and where it matches how people actually talk it works as a fair proxy. Where it does not, the product follows the real conversations rather than the reporting lines. Which means the product is often a better map of how a company communicates than its own chart is. The reason becomes obvious once it is said aloud: people can only design what they can talk about, and they can only talk across the channels that already exist. Where the channel between two teams is thin, the connection between their two components will be thin, awkward and late. Almost every clunky handoff a customer feels is a thin communication channel made physical. The practical move, which engineering teams now use deliberately and call the reverse Conway maneuver, is to stop fighting the mirroring and use it. Decide what you want the product to look like, then arrange the teams to match, because the mirroring will happen either way and the only real choice is whether it happens on purpose. One honest limit: the research shows the correspondence clearly but does not settle which direction the causation runs, and documented exceptions exist, so treat it as a strong tendency rather than an iron law.

The claim covers systems an organisation designs, not software it buys. Purchased middleware, a database, a payments provider: none of those mirror your org chart, because none of them were designed by your teams. They mirror the vendor's. What does still belong to you is the decision about which pieces to buy, where to draw the lines between them, and which teams own each boundary, and those decisions are made through your own communication channels like everything else. So a company with two departments that barely speak does not escape the pattern by buying an integration layer. It usually ends up paying for one, and the layer it buys is the visible price of the conversation that never happened.

Source: Melvin Conway, How Do Committees Invent?, Datamation, April 1968, with the author's own note added decades later. Empirical test: MacCormack, Baldwin and Rusnak, Exploring the Duality Between Product and Organizational Architectures, Research Policy, 2012. On the limits: Colfer and Baldwin, The Mirroring Hypothesis, Theory, Evidence and Exceptions, 2016.

Team Topologies

Matthew Skelton and Manuel Pais, 2019

On arranging teams around the product you intend to ship, since the shape of the organisation will show up in the product regardless.