image credit: Manu Cornet

In 1967, Harvard Business Review rejected a paper submitted by Mel Conway. A year later, Conway’s thesis would be dubbed Conway’s Law. Conway graduated from Caltech with a Masters in physics and from Case Western Reserve with PhD in math. He worked on the Pascal compiler among other notable software projects. Over the course of his career, Conway observed a phenomenon. The products software teams created reflected their organizational structure.

Let’s make that concept a bit more tangible. Nigel Bevan, a usability expert wrote, “Organizations often produce websites with the content and structure that mirrors the internal concerns of the organization rather than the needs of the website.” In other words, the marketing team has a webpage. The sales team has a webpage. The public relations team has a webpage. Rather than reflecting the realities of the customer journey, the internal structure of a company dictates its product architecture.

Conway’s Law arises in software development projects. Put three front-end engineers on the same project and the user will have three different ways of accomplishing every task: point-and-click, keyboard shortcut, menu item. If you have two different heads of engineering within a company, there will likely be two different source control systems, two different code-checkin processes, two different architectures and so on.

In 2008, Alan MacCormack and his co-authors researched and validated Conway’s Law in HBR by studying the software produced by companies and contrasting that with open source software produced by communities.

I’m not sure the law is truly a law, that it is universally true. But it does raise the question of whether or not a startup’s teams are properly structured. For example, most fast-growing companies start off building a monolithic application (one app server, one database, one logic tier) and eventually migrate to a microservices architecture, where the functionality that used to be encapsulated within one codebase are fragmented into tens or hundreds of different services.

One could argue this is a reflection of two forces: the growing size of the engineering team and the rise of devops where developers are responsible not only for coding but also quality assurance and operations. So, small teams of developers can become nearly fully independent of the larger engineering organization. Hence microservices.

Unfortunately, Conway’s Law does not provide a diagnostic tool to help executive teams determine whether or not their organizations are properly structured, nor when a reorganization of a company might make sense. It only raises the question: Does our organizational structure lend itself to building the best product for our customer?

And that is a very good question to ask periodically.

Image credit Manu Cornet