systems engineering//Conway's law

Conway's law is the observation, stated by Melvin Conway in 1968, that organizations design systems whose structure copies their own communication structure; it is used in engineering management to predict where a system's interfaces will fall and where its defects will concentrate, and to arrange teams so that the architecture you want is the one the organization naturally produces. If the estimator team and the control team of an autopilot sit apart and rarely talk, the interface between estimator and controller is where the errors will live: units assumed differently, a covariance nobody passes on, a timestamp one side expects and the other never fills.

Conway's law is the observation, stated by Melvin Conway in 1968, that organizations design systems whose structure copies their own communication structure; it is used in engineering management to predict where a system's interfaces will fall and where its defects will concentrate, and to arrange teams so that the architecture you want is the one the organization naturally produces. If the estimator team and the control team of an autopilot sit apart and rarely talk, the interface between estimator and controller is where the errors will live: units assumed differently, a covariance nobody passes on, a timestamp one side expects and the other never fills.

The mechanism is mundane. Each team optimizes what it owns and negotiates only what it must, through the channels it has; a boundary that requires daily conversation becomes, between teams who meet monthly, a frozen interface document with gaps nobody owns. So the module boundaries of the delivered system mirror the org chart, whether or not that division suits the problem.

Put the boundary where the coupling is weak. The estimator and the controller of a drone are tightly coupled (the controller's gains depend on the estimator's delay and noise), so splitting them across teams invites trouble; splitting by vehicle subsystem with one owner of the whole loop matches the physics. Some companies reorganize teams on purpose to get the architecture they want, sometimes called the inverse Conway manoeuvre.

It is the centralized-versus-distributed question applied to people. A fleet architecture centralizes while it can because one centre has one log and one truth; an organization with one owner of a critical loop has the same advantage, and one split across teams pays coordination cost at every interface.

The defects it predicts are integration defects, the ones unit tests do not catch because each side is right by its own specification. They surface late, in hardware-in-the-loop or in the field, which is why the V-model verifies interfaces explicitly at the integration level.

Its limit is that it describes a tendency with exceptions. Strong shared tooling, a common simulator and an architect who owns the interfaces can make a system less like the org chart than it would otherwise be.

The law belongs to systems engineering, next to total cost of ownership, where the cost of coordination is counted.