How Your Startup’s Org Chart Changes Your Product

How Your Startup’s Org Chart Changes Your Product


In 1967, Harvard Business Review rejected a paper submitted by Mel Conway. A year later, Conway’s thesis would eventually 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


[Tomasz Tunguz]

June 29, 2016 / by / in , , , , , , , ,

Leave a Reply

Show Buttons
Hide Buttons

IMPORTANT MESSAGE: is a website owned and operated by Scooblr, Inc. By accessing this website and any pages thereof, you agree to be bound by the Terms of Use and Privacy Policy, as amended from time to time. Scooblr, Inc. does not verify or assure that information provided by any company offering services is accurate or complete or that the valuation is appropriate. Neither Scooblr nor any of its directors, officers, employees, representatives, affiliates or agents shall have any liability whatsoever arising, for any error or incompleteness of fact or opinion in, or lack of care in the preparation or publication, of the materials posted on this website. Scooblr does not give advice, provide analysis or recommendations regarding any offering, service posted on the website. The information on this website does not constitute an offer of, or the solicitation of an offer to buy or subscribe for, any services to any person in any jurisdiction to whom or in which such offer or solicitation is unlawful.