One of the more common responsibilities of a VP of Engineering joining an early stage startup, around the series-A stage, is to scale an engineering team. The simple way of looking at this endeavor is to assume that this task is just a matter of hiring more engineers. Nothing could be further than the truth. Hiring is the tip of the spear and represents a fraction of the challenges the engineering team will face. In this post, I cover some of these challenges
Productivity
The desire to scale an engineering organization often stems from the need to increase the velocity of product development, which should happen in the long-term. In the short-term, meaning over the first 6-12 months of scaling, the team productivity will likely drop. This is counter-intuitive, especially for the rest of the business who make a linear assumption: more engineers implies more features. In time, this should be true, but initially it will not. Scaling a team is a big investment spanning two major efforts: hiring and onboarding.
In my experience it takes interviewing anywhere from 5-10 candidates to make a single software engineering hire. The range is a function of the technical bar and the competitiveness of the software engineering market. If you structure your interviews well, you should be filtering candidates out earlier in the process and only progressing ones who have a high chance of both passing the entire interview and accepting. The average time a candidate will spend interviewing, regardless of how far or early in the process they make it, tends to be 4 hours spanning a recruiter screen, hiring manager screen and ~2 technical interviews. Therefore to hire 10 engineers you will need to invest anywhere from 200 (5x4x10) to 400 (10x4x10) 400 hours. That’s anywhere from 10% to 20% of the working hours of a single engineer per year (assuming 2000 hrs/year). More critically, this doesn’t take into effect the impact of context switching between interviewing and product development. Context switching takes its toll and has a big impact on productivity.
Congratulations, you’ve hired 10 more engineers and doubled your team. You now have a bigger challenge on hand; making those engineers productive. It is not unusual, during that first scaling period to end up with a bi-modal distribution of tenure amongst the engineering team. Half of your team will have been with the company since the very early days, and the other half very recent.
Therefore, the onus on onboarding all of these new hires will fall on the more tenured, and critically more productive, engineers. This again results in a drop in the overall team productivity.
Process
Process tends to be a foul word in startups. It reeks of bureaucracy and slowing things down, which can be absolutely true. However, as an engineering team scales the processes (or lack of) that the team relied on to plan, build and release software will not necessarily scale. The main reason isn’t intrinsic to the engineering team alone. It has to do with the rest of the company growing as well.
A startup scaling its engineering team is almost certainly starting to invest in building new, or scaling other organizations. The most common being sales, marketing, people, support, customer success and finance. The introduction of all of these new teams introduces new points of collaboration, communication and alignment, as depicted in the diagram below.
What used to happen organically and very rapidly with a few engineers huddling, now requires planning and explicit collaboration. For example, what features will be worked on and when they will be released might now require explicit collaboration between engineering, product management, sales, customer success, marketing and support. The latter three likely being new to the company.
The processes introduced can also be intrinsic to the engineering team. It’s not unusual in the early days to not have a DevOps team. Releasing new software is done by the software engineering team. So is managing the infrastructure - dev/test, prod, build and so on. As the team starts to grow, these functions will be handled by a dedicated team, who will start introducing explicit processes on access to infrastructure and release management amongst others. The one advice I will give on process, is to only introduce it to solve a problem(s) and ensure that the process actually solves it.
People
Another area that starts to creak and show signs of tension is the organizational structure of the engineering team. It isn’t unusual to solely target software developers during that initial scale-up of the team. One role that is often overlooked during that period is that of the engineering manager. Not only is this role important to efficiently scale the team, it is also one of the harder ones to fill.
If your experience is like mine you will find out that most of your existing software engineers are reluctant to move to a manager position. This leaves you with one option; to recruit externally for this position. I have found that this is one of the harder positions to fill. I have almost always ended up with an org chart that looks like the below, at least during the initial phases of scaling the team. Try to avoid getting there, or at least be aware of this issue and plan for it.
Hiring managers isn’t the only challenges you will face on the People side of things. You should be investing in more People programs. I have often found that this first point of scaling offers a great opportunity for engineering teams to codify their values. These are the traits engineers care deeply about and are the universal attributes that every team members should exhibit. Investing in defining your values will be a huge asset to help onboard new hires.
You should also look into structuring a well defined and repeatable onboarding process, along with a buddy system or mentoring. The more you invest in your People programs, the lesser the impact of the scaling the team.
Conclusion
The post’s title is deliberately provoking, and, slightly incorrect. In the short-term, you should expect a noticeable dip in your team’s productivity. However, your team should be more productive in the long term, assuming you solved for the challenges - and others - that I outlined here.
Scaling is hard and requires deliberate investments beyond hiring. As an engineering leader you need to set the right level of expectations within your team and more importantly with other parts of the organization on the impact of scaling. The most common mis-alignment tends to be the perceived productivity gap. Some parts of the organization will assume that the more engineers you hire, the faster the speed of product development. You need to temper those expectations and work with your team on slowly driving productivity upwards as you solve some of the challenges you will inevitably face.
Things I am reading/listening to
Why Developers Are Building So Many Side Projects Interesting article on how side projects can become a side-business and good source of income. This in addition to the learning opportunities they provide
If the US were a company, I would posit that one of its main competitive advantages is recruiting. The ability to attract great talent at a global scale is a huge advantage that should be maintained.
The Rise and Fall of the Third Reich: A History of Nazi Germany A very well written and detailed read on the Third Reich. Eye opener for sure, especially on the slippery slope from democracy to Hitler.
Doom, Quake, VR. Enough said!