--- title: "How Your Startup's Org Chart Changes Your Product" description: "Discover how Conway's Law shapes startup product development and team structure. Learn why your company's org chart directly impacts customer experience and product architecture." categories: ["management"] keywords: ["Conway's Law","startup organizational structure","product development","software architecture","microservices","team dynamics","customer experience","venture capital","SaaS","Tomasz Tunguz"] ai_summary: "Explore how your startup's org chart influences product design and customer experience through Conway's Law." date: 2016-01-08 lastmod: 2026-07-30 canonical_url: https://www.tomtunguz.com/conways-law/ author: "Tomasz Tunguz" --- ![image](https://res.cloudinary.com/dzawgnnlr/image/upload/q_auto/f_auto/w_auto/conways_law_cornet.png) [image credit: Manu Cornet](https://bonkersworld.net/organizational-charts) 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](https://dzone.com/articles/conways-law-v-software): 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](http://www.hbs.edu/faculty/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf) 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](http://arstechnica.com/information-technology/2016/05/blow-that-data-monolith-to-smithereens-with-microservices-and-database-swarms/) 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](https://en.wikipedia.org/wiki/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](http://www.bonkersworld.net/)*