04/19/23
Translating Strategy to Code
building software organization structure to meet business needs – inverse conway’s law and emergence
This piece is written in collaboration with Krishna Bala, Senior Vice President of Engineering at Proscia.
Krishna has been deploying the strategy behind Conway’s law to scale various engineering teams throughout his career. Conway's law suggests that the structure of an organization's communication channels and workflow will be mirrored in the products or systems they produce. By intentionally designing team structure to align with product goals, Krishna has helped achieve significant growth and success. His leadership and expertise have been invaluable in guiding teams towards a culture of innovation, collaboration, and excellence.
In one of his papers titled "How Do Committees Invent?" published in 1968, Dr. Melvin Conway recounted a story about an eight-person team at a contract research organization. Their task was to develop two compilers: one for COBOL and the other for ALGOL. The team assigned five members to work on the COBOL compiler and three members to work on the ALGOL compiler. As a result, the COBOL compiler had to be designed in five phases while the ALGOL compiler only needed three. This anecdote gave rise to what we now refer to as Conway's Law, which states that the design of systems by organizations reflects their communication structures.
"organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations."
In other words, the structure and communication patterns of an organization will be reflected in the software systems it produces. This means that if an organization is highly centralized with a rigid hierarchy, the software systems it produces are likely to be similarly centralized and hierarchical. On the other hand, if an organization is decentralized with a more fluid structure, the software systems it produces are likely to be more decentralized and flexible.
Conway's Law highlights the importance of communication and collaboration within an organization, as well as the need for organizations to align their structure and processes with the goals of their software development efforts. It also suggests that changing the structure of an organization can have a significant impact on the design of its software systems.
Deploying Conway’s Law
The following is a case study made of an amalgamation of Krishna’s experiences building and scaling engineering teams written in his POV.
Early Days
When I start growing early-stage companies, there are usually three or four engineers at the beginning. I have worked mainly in software development, where there are multiple products with common technology elements – typical B2B or B2C SaaS.
The engineers are balanced between different product teams resulting in less than ideal allocation to meet all the needs of the business. The founders realize that it is time to scale engineering and product output.
Scaling engineers
So by the time I get in, there’s a genuine need to scale engineering. This is the engine that drives the revenue of the company. The founders want to get someone who can build that organization.
Right from the beginning, I am sensitive to, when would Conway's Law start to apply to our organization? But my first goal isn’t that.
My first goal is: I just need to hire 20 plus engineers – the best quality engineers we can afford. To bring them on, inspire them, give them the best tools we can afford, and then essentially get them to start working on these products. At that time, I start to plan strategy – as we hire more people, I'll have to create an organization structure and it better be the structure that our business wants.
This is where the inverse comes in. The previous paradigm leads to what Allan Kelly defined as the Reverse of Conway’s law:
Organizations with long-lived systems will adopt a structure modeled on the system. Organizational design is system design. Architect the organization to architect the system.
Essentially, building bottom’s up – the codebase doesn’t determine the structure of the team. Design the structure of the team in the way you want your software to look.
Reverse engineer Conway’s Law
What I do first is feed each product organization with engineers.
So initially, I don't think too much about the boundaries because the organization is starving for hands-on-keyboard. There aren't enough engineers. Let's push the engineers in.
We get the engineers in, then I start to observe Conway's Law. You start to notice in multiple-product companies that the law initially works against us. Product 1 builds something that Product 2 doesn’t use and vice-versa.
At this point – the question to ask is – what is the quickest way we can break the organizational boundaries so that more information flows back and forth? How do I increase communication between the engineers?
Cross-pollination
First thing I do is I criss-cross some engineers. Move them from Product 1 to Product 2 and vice-versa. That immediately shows significant value. Every time there is something to build, we can just borrow it from the other product. Lots of “Don’t build it! We have it in product 2!” or “Let’s put the right contractual interfaces in place so we can reuse that”.
Second thing, I create engineering team leads for each of the product organizations as the engineering team scales. With team leads, there is more communication, and the silos often start to fall further.
Core Team inversing Conway’s Law
Now, engineers are rushing and dashing to the finish line. The two teams are writing code and delivering it, and some silos are building up. At this point – that’s okay. We deliberately decide to take on tech debt and pay it down later or over a period of time.
When you’re moving this fast in a startup, you deliberately take on tech debt to address your market needs, your customers’ needs and you start building in that market. And as you start building that up, this core group then starts to observe with a retrospective look and says – “I won’t build this twice.”
To solve the problem of silos, I often build a core engineering team, a team that builds common/shared features for the different product organizations: Inversing Conway’s Law! For instance, a common asset that a lot of product teams rely on is APIs. I invest in building out common APIs for all products.
As the Core team grows, they advertise what they’ve built to Product Managers. As the team grows, the Core group gets stronger, being able to influence the 1+1=4. (an ode to emergence in self-organizing complex systems)
Future Evolution
As we start to scale and grow the organization, we evolve deeper towards the Spotify model with Squads continuing to be their basic unit of development.
Spotify has a model on their adaptation of Agile Scrum practices at scale. I really like this concept, which basically says to create squads that directly work toward product groups. However, you form those squads, from people who have experience in all common elements. So there are people who are coming in from front end UI/UX, backend/API, DevOps and database as an example.
You form these squads based on the capacity needs of the business. Lets say, we want to prioritize a lot of Product 2 activities for the next six months. We would still be investing in Product 1, but we want to wait for the market to give us feedback. We would put two fully staffed squads – a typical squad of two-pizza-rule (a team small enough to be fed by two pizzas) – on Product 2 and let them work on the backlog, feature requests, bugs, tech debt, whatever it needs. And give Product 1, one squad.
My long term evolution approach is where I work with product management to assess their capacity needs and staff teams based on those needs. Engineers are all cross-trained and become experts in various parts of the tech stack.
The challenge as we evolve is we’re always going to need a few leads that are domain experts in each squad – people who are extremely familiar with their customer segment.
We also cannot deliver code as a monolith. We need to have a certain output for Product 1, and we need to have a certain output for Product 2. Their workflows might be different. Their UX/UI might be different. Their respective front-end and customer engagement might be different. So, I would have squads with those types of leads.
Perhaps a couple of leads on each team. One lead and one senior engineer that stays permanently there. People that stay on their squad all the time with domain expertise. This would be my evolution approach.
Spotify squads, tribes, chapters, guilds
More on Krishna Bala
Krishna is currently Sr. VP of Engineering at Proscia developing enterprise SaaS products that enable computational digital pathology for oncology. He is an experienced healthcare technologist with more than 20 years of experience in software development including data analytics and AI/Machine-Learning. Krishna has been an entrepreneur with several successful exits and was most recently VP of Engineering at ResMed, a $30 Billion+ company focused on digital healthcare and breathing disorders. He has a Ph.D. in Electrical Engineering from Columbia University in New York.
Krishna lives in NYC with his wife and 2 kids. He enjoys reading and taking long walks exploring NYC with his wife.
References:
https://mikefisher.substack.com/p/org-charts-and-architectures
https://thinkinsights.net/strategy/conways-law/
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
This piece is 19/50 of my 50 days of learning. Subscribe to hear about new posts.