Top cost drivers in a VPE's budget
Top cost drivers in a VPE's budget
People + Infrastructure
It’s this magical time of the year, and no, I am not talking about the US holiday season. I am referring to corporate planning and budgeting! I know that budgeting can elicit a negative reaction, but it is a critical planning exercise. It’s also one I have come to enjoy doing.
In this post I will focus on budgeting for an engineering org. I will cover the main elements that I expect to see in a software engineering department’s budget, how to model them and more critically why they matter, especially to the business. I will not be addressing holistic planning and budgeting for the entire company. For a great read on this, I recommend Shomik’s excellent post
People, people and more people!
It should come as no surprise the largest element in a VPE’s budget is headcount. In my experience it’s anywhere from 60-80% of your entire budget. When modeling for headcount you should take two important factors into consideration. The first, is the incremental headcount you need. This represents net new additions to your team. The second is the incremental salary and equity increases to your existing team. There are also some other costs that are proportional to your headcount. Examples include traveling for conferences, on-sites, laptops and so on.
New hires
I will first outline the set of questions you need to address first before you are able to model for incremental headcount. These questions will also help you understand why you need this incremental headcount.
How many new hires do you need Not only should you project the number of hires you need, but you should also think about the profile of each. Do you need them all to be Staff level software engineers or a mix of junior and senior? Do you need managers? You must work with your recruiting team to understand the compensation expectations for each of your profiles. Armed with the compensation expectations you can now project how many hires per profile you need and therefore, how much these hires would cost. Don’t forget to take into consideration churn when planning for new hires. You will lose members of your team.
When do you need them Timing matters both in terms of impact and cash flows. If you make all your hires at the end of your fiscal year, you incur the least amount of cash burn in that year. However you will get no benefit from these hires either (within that fiscal year). Conversely, if you make all your hires on the first day of your fiscal year, you burn the most cash, yet should be able to get the most results of these new hires. Another important reason to think of timing is the productivity impact of hiring to your existing team. Your recruiting team will also want to see the timing of these hiring to project their own bandwidth and needs.
Why do you need them It’s easy to default to “I need more engineers”. This has been the mantra of the past decade or so in tech firms, and admittedly hasn’t ended up all too well. Witness the continuous layoffs. Putting aside marketing gyrations, you must always anchor your hiring needs to business outcomes, especially if your company (most startups aren’t) isn’t cash flow positive. You are making these hires, which incur incremental cash burn, but will result in some business outcomes. When I model my hiring, I try to project the incremental product development lanes - synonymous with teams - that I can open up. Each lane, therefore offers an incremental channel of product development.
The number of net new hires you project should also drive incremental spend on equipment, SaaS seats and other office supplies. The most common cost items in this category tend to be laptops and additional seats for SaaS or other tools your engineering team uses.
Existing employees
There are two cost categories for existing employees. The first is compensation increases and the second is a per headcount allocation that covers ancillary costs. For compensation, you should work with your HR and Finance team to allocate a merit (and bonus, if applicable) budget. This is the pool of cash and equity that you can give to your existing team members for promotions, recognition for outstanding work and so on. Make sure you set this budget item aside! The “other” or ancillary costs that you should budget tend to be things like training, traveling and conferences.
Infrastructure
Your infrastructure costs cover all the servers, networking, storage and tooling that you need to build, test and deliver your products. This cost bucket tends to be the second largest, sometimes even the largest, in a VPE’s budget. It is also one of the more complex to model, because there are many moving parts to it. However, if you don’t model it then I posit that you do not understand it and are at risk of runaway costs, or the inability to have your infrastructure scale with your business.
Therefore, I always start from the drivers of my infrastructure costs. Said otherwise, what are the inputs that drive these costs higher and how do these inputs correlate to cost. In my experience there are two key inputs: headcount and product usage.
Headcount drives the build/dev/test elements of your infrastructure costs. The more engineers you hire, the more commit activity (hopefully), the more tests to run and the more product to build. When modeling costs driven by headcount, I try to assess if the incremental cost is warranted or whether it is time to optimize it. This really is a matter of trying to evaluate whether you roll with the incremental cost, or invest to optimize it. An example might help.
Years ago, I was at a startup that developed on-premises software. The software was delivered on rack-able servers. In the early days, each engineer had access to their own servers. They would use that for dev/test. Each additional hire implied more servers to purchase. That model works well when the team was relatively small. At some point though, the incremental (and overall cost) became problematic. We optimized this cost out by investing in virtual appliances that allowed the engineers to test against them versus real servers. The real servers were pooled and used for CI/CD and performance/stress tests. This investment required us to build the test fixtures and virtual appliances and hence the tradeoff: $ vs engineering time.
Next, is the real cost. The infrastructure that powers your products. This can be quite high for SaaS companies and has impacts far beyond engineering. The same modeling exercise applies. What are the key drivers for incremental infrastructure resources for my SaaS?
The answer is typically usage. The more customers you acquire, the more usage they incur and therefore the more infrastructure you (might) need. The challenge is in trying to model this usage and understanding how it drives incremental resources, and which ones.
Building this model is helpful for two reasons. First, it allows you to understand how your infrastructure scales relative to your business. If growth of $1 in your business implies your infrastructure costs also growing by $1, then you’re in trouble. You’re in trouble way before $1, but you get the gist of it.
Second, by doing this exercise you are now able to make tradeoffs. It’s incredibly simple to mask out a performance bottleneck in your product by spending more on infrastructure. Throw more EC2 and a cache at it. The challenge with this approach is it doesn’t scale well, in terms of cost. Sometimes throwing more EC2 at it is the right thing to do, due to resource constraints. But just knowing that you are masking it and that it can and should be optimized is advantageous.
Another element in your modeling is what I call “Step Functions” in your infrastructure costs. Perhaps you run your SaaS in a few AWS regions and plan to expand for regulatory or business reasons (e.g. FedRAMP) beyond these regions. Each regional expansion represents a significant cost and therefore should be modeled and outlined in your budget. Remember, this spend impacts your margins. It matters.
Because of the very fluid nature of this cost category, you should observe it on an almost continuous basis. It’s far too easy to have runaway cloud costs!
Other, miscellaneous costs
Headcount along with costs relative to that and infrastructure represent almost the entirety of an engineering department’s budget. There are a few other items that can incur relatively large costs that are worth noting.
The first is patents. If you’ve ever gone through a patent application process or worked with a patent law firm you know all too well how expensive these are. Filing 10 patents will easily cost you $250K+.
The second are professional services, consulting or other contracting fees. Those are rare, but if you have them you should budget for them.
I mentioned earlier that I enjoy budgeting. There’s an analytical aspect to it, especially when modeling costs. The more salient aspect of budgeting is tying the cost model with business outcomes. Connecting these two dots helps me better understand the business of running a software development organization.
One final note on this exercise. Your annual budget tends to be an ongoing exercise. Planning is essential, but life - especially in the volatility of startups - has a tendency to not agree with your plans. You should plan to review and adjust your budget on a quarterly basis based on business attainments and how well your plans have come to fruition.
Thanks a lot Karim for sharing so much insights about a VPE role