Conway’s Law is named after computer programmer Kevin Conway, who in 1967 stated:
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
In other words: you ship your org chart.
This is often cited as a reason why many software architecture projects fail to live up to their promise.
You can have all the design documents, RFCs, and agreements from stakeholders you like, but if the proposed model doesn’t take into account the existing team structures and communication lines, you’re like King Cnut ordering the tide to stop coming in.
This leads to one of my favourite ideas from software development theory, the ‘Inverse Conway Manoeuvre’. I love it in part because it sounds like something from Star Trek, but mainly because it highlights how fundamentally human software is.
If Conway’s Law states that software designs 'are copies of the communication structures of…organizations’, then logically, it follows that by changing the shape of your organisation you also change the shape of your software.
Said another way, you can powerfully change the efficiency and operation of your software technology by changing the shape and makeup of the teams building and operating it.
This might seem somewhat obvious in many ways, but I can assure you that when software systems start malfunctioning or degrading in some way, it’s the code that is the first thing people look to change, improve, or ‘solve’ - not the structures that created it.
So next time you see some conflict over API interfaces, comment warfare in Pull Requests, new standards being quietly ignored despite endless reminders, or tickets sitting blocked for weeks on end, take a beat. Is it the software, or a human communication issue you're encountering?
If you are experiencing issues with communication in your teams, or you simply want to improve your communication skills with others, check out a presentation on the Non-Violent Communication framework and how it’s been instrumental in my tech career.
You can also read more about my experience with NVC here:
The most valuable framework in my tech career
Within a week into my new role as an Engineering Manager at a London Fintech startup, I was pitching the founders on running a workshop for the whole company. A few weeks later, I delivered it, with half the room full of people I hadn’t even met yet.