Harnessing Conway's Law
How the structure of your communication determines the type of product you build
Building any product is difficult. Rebuilding an existing product that has customers and been in production for several years is very difficult.
One of the mistakes I repeatedly made in my product development journey is not adapting to its stage with how I structured teams. It is an error that one doesn't see very quickly in the beginning and compounds if left unchecked.
A couple of years ago, I read about Conway's Law. So what exactly is Conway's Law?
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
- Conway, 1967
This quote is from a paper he published called How Do Committees Invent? (Links can are in the resources section)
Product teams come in all shapes and sizes. If we have a team co-located and can communicate freely, they end up building software that will tend to be more monolith. Open source product teams are usually distributed and build products that mirrors a modular-based product.
For founders and leaders who are building products, they must pay a lot of attention to how they want their teams to communicate. Sounds simple yet the smallest of details can derail development projects. Some of the mistakes I have made and still do make are:
When the conversation is very top-down heavy, we lose feedback loops and often teams end up building the wrong things, and all the effort in creating a great product goes to waste.
When we allow strong developers to make changes without enforcing strict code-breaking rules, this mistake promotes elitism and very soon you can devolve into an 'us vs them' scenario.
When product teams do not actively collaborate with engineering teams, we suffer from information taking longer to get to the right people. Resulting in wasted effort and release delays.
Poor communication without proper documentation confuses the team where we are going and why we are taking a specific path. Engineering blames product teams and vice versa.
As we are in the early stages of the project, some of the things that I have found to bring better visibility and communication are:
The founder or project leads need to create a map of the entire application and have a skeleton of how things will be interconnected.
Short sprint cycles in the early days are critical. At the moment we are running one-week cycles to ensure that we do not overbuild.
We are an entirely distributed team; the tools we use are critical. We are using Linear for issue logging and extensively use notion to keep track of meetings, notes and customer interactions.
We have automated async stand-ups that give everyone visibility as to what they are doing and have a short 30-minute meeting every day to bring up any blockers.
We have a show and tell session on Friday to log the week's work and record what we have achieved.
The mistake teams make is that they do not adjust as they progress in the product development cycle. If we can keep our processes agile and continually tweak our practices as we go, we will not have rigid processes that could endanger the build processes in six months.
🧰 Resources
The original paper which stated the law. Initially, Harvard rejected the paper until they ran a study that found the correlation between the organization’s structure and the products that they were building. Dense but a good read.
📝 How to dissolve communication barriers in your development organization
This post talks about API development and using Postman as a tool to bring more transparency in your communication. Overall I believe it does a good job of showing how multiple structures can achieve a strong communication culture.
📹 Don’t Forget Conway’s Law - Sarah Novotny Keynote
If you do not want to read long articles about the topic and want to get the law in a short 9-minute video, this is a good one. The video focuses on moving from a monolith application to a microservice architecture.