Conway's Law

Conway’s Law is an observation about how companies build technology. It originates from Melvin Conway, an American computer scientist, who wrote it down in 1968. His statement, in short: A product ends up with the same structure as the group of people who developed it. If four teams work on an app and each team stays to itself, four clearly separated building blocks emerge almost inevitably. And the interfaces between these building blocks look exactly like the communication between the teams: smooth, if the people talk daily, bumpy, if they don’t. Conway’s Law is not a law of nature, but a rule of thumb that keeps proving itself in practice.

Why organizational charts end up in the software

For companies, this is an uncomfortable insight. You cannot freely plan a technical solution if the company doesn’t fit it. A company with rigid departmental boundaries will hardly produce a smoothly interacting product. The boundaries of the departments reappear in the product, just this time as technical fault lines.

This becomes especially visible in old, large corporations. Banks often have an app in which the securities account, the loan, and the checking account feel completely different. This is rarely due to bad programmers. It’s because three separate departments with their own budgets and their own systems are behind it. The customer feels the bank’s organizational chart without ever having seen it.

Conversely, some companies use this effect deliberately. This is then called the “inverse Conway maneuver”: First, you consider what structure the product should have. Then you rebuild the teams exactly so that this structure can emerge. The organization thus becomes a tool of technical planning, not an obstacle to it.

The mechanism behind the observation

The core issue is communication overhead. For two pieces of software to work together cleanly, the people behind them must agree on many details. What data is passed? In what format? What happens in case of an error? Such agreements are laborious and take time.

Within a team, these agreements are cheap. You sit together, ask a quick question, change something the same day. Between two departments at two locations, the same question costs a week and three meetings. Developers instinctively avoid this effort. Instead, they define an interface that is as rigid and as simple as possible and then leave each other alone. That is exactly where the dividing line in the product emerges.

A fitting analogy is the construction of a house by two firms, each taking on one half. They will agree on a straight dividing wall, because anything else would require constant consultation. An interlocking, open floor plan spanning both halves would be possible, but only with a great deal of coordination. The result ultimately shows how the firms dealt with each other.

From microservices to AI teams

In tech news, Conway’s Law often comes up in the context of microservices. This refers to software broken down into many small, independently running services. Companies like Amazon or Spotify have accordingly formed small, independent teams that are solely responsible for their service. This team structure is not a footnote, but the prerequisite for the technology to work.

The effect is also seen in AI products. If a company has one team for the language model, a second for search, and a third for the user interface, this shows in the result. The chatbot answers questions well but finds documents poorly, or vice versa. Mergers are another classic case: after two companies merge, two separate system landscapes often remain in place for years, because the two workforces also remain separate.

A common misconception is to read Conway’s Law as an assignment of blame to individual developers. It does not describe a failure, but a structural force. Anyone who wants to change the technical architecture must therefore usually start by addressing collaboration first. Rebuilding the software alone rarely holds up for long if the old departmental boundaries remain in place.