Premature optimization is the root of all evil


An antipattern that I see in startups constantly is Senioritis. This normally happens when the startup finds some success and wants to upgrade its product and engineering teams. Typically at this stage, new leaders are hired and there is a we need to grow up vibe. These new leaders typically are hired from established companies/startups and bring with them their approaches. All startups start as a monolith. You have a 5-10 engineers who are full stack and with maybe 1 PM (mostly the founder). The code is a monolith and the organization is a monolith that is optimized for speed. The team iterates and ships quickly and constantly. The founder decides its time to grow up and hires its first C level hire (CTO/CPO).

The first thing a new leader will do is to try to design an organization for scale. There will be a tendency to over-engineer the organization. The word microservices will start to appear :). The reasoning will be laid out as follows

  • To scale, we need to break out our system into microservices
  • We need to align our organizational design to this approach because Conway’s law
  • We also need to beef up our infrastructure/security teams as we are now in the big leagues
  • We need senior experienced talent in each of these new areas

All around this thinking is welcome to everybody in the company. The engineers will like it because – hey micro-services. Also, teams are being formed so more possibility of growth for me! More teams ? more possibility of team leads – presto career growth. Every functional group will love it, more teams equal more people equals growth for me.
The new leader will love it as he can now go hire other leaders to fill out those sub-organizations. You will need a head of platform engineering, you will need a head of infrastructure, and so on. The leaders of these groups will get hired first, see the head of problem.

We now have a great org designed, hired all the right people in leadership roles – now we are grown up!

And contrary to what you’d expect – EVERYTHING slows down to a crawl. Nothing gets done.


This is a classic case of premature optimization. In the quest to scale and build out the organization you made the entire system sub-scale. Previously you had a group of people delivering code as a unit – but now you split that unit up into multiple teams. Each of these teams now only has 1-2 engineers on them and cannot ship an entire functional unit of software. Each team now has to talk to the other team and excessively coordinate across the same code base to deliver software. Splitting up the team into so many sub-teams also causes a diffusion in responsibility. My team is only responsible for this service and – so that’s all that we focus on, shipping code to the customer be damned.
A better way to avoid this anti-pattern is to focus on the actual productive resources first guided by a mental and capacity model. Having specialized groups that tackle specific problems is good – at scale, you will need a separate DevOps team, a few separate feature teams, etc. But the trick is to not go directly to the end state. You should evolve the organization organically, starting with productive resources.

What do I mean by productive resources?

For engineering teams – it is the actual engineers committing code. For product teams, its the PM’s and designers who are doing the work. These are your most important and hard to hire resources. Always scale these first before scaling the non-productive resources (aka management :)). You don’t need a head of infrastructure engineering first, you need at-least 5 infrastructure engineers. A good rule of thumb is to only break out a sub-function out of the monolith if there is work for 5 productive resources in that sub-function. Hire those 5 engineers first before hiring the overhead (manager). Also, have a strict capacity ratio for hiring that is based on the engineering hiring model. A model that I’ve seen work is a base pod is 5 Engg + 1 PM + 1 Designer. An engineering manager can manage 2 Pods. A PM manager can manage 5 PM.

The above model is easy to say but extremely hard to do in practice. As leaders, you have to fight the urge to conflate leadership hires and growth in the rate of leadership hiring with actual growth of the output of the organization. Your customers only care about working software that solves their problems, they do not care about how your organization looks like!

Leave a Reply