Skip to content
Engineering Investment and Business Alignment

Balancing Code and Cash: Annual Budget Planning for Software Engineering Teams

Software engineering teams are one of the most significant resources that companies invest in. For most companies, R&D investments represent a significant part of how a company intends to differentiate itself, innovate, disrupt new markets, etc. Over the past year, teams are expected to do all of that in the context of constraints and with more of an eye to efficiency in order to navigate through some of these economic times. This puts increased emphasis on the importance of getting budget planning right. 2023 was deemed the “year of efficiency” and 2024 could be a similar economic environment. 

The key question is: how do we reconcile our ambitious delivery plans with these new constraints? Budgeting isn’t necessarily the most fun topic, and it’s also not widely taught in the engineering function. But right now, it’s an essential skill that’s required in order to make sound strategic decisions regarding where resources should be allocated in the coming year. 

In this post, we’ll recap a conversation between our Head of Product, Head of Engineering, and a Senior Engineering Manager to shed light on budget planning best practices for R&D organizations. The goal is to shed light on guiding principles from years of engineering experience to apply to annual budget planning. 

What’s been different about budget planning in your role this year? What was more challenging?

Krishna Kannan, Head of Product at Jellyfish: Budget planning was different this year, and I think two things have happened. One is the maturity of Jellyfish has increased over the last couple years. Eli alluded to growing from a small team to several hundred now. So part of it is just the natural growth and maturity of the company here. 

Eli Daniel, Head of Engineering at Jellyfish: So comparing to last year and comparing to other roles that I’ve had, this year was different in two ways. One was that the actual speed with which we did budget planning and the speed at which changes in the market were influencing that budget planning was new. The market’s very dynamic right now. The climate is changing, and so you have to be nimble in your planning as well. 

The second thing was different because of that change that we’re seeing. We went through more of a scenario-based approach to budget planning than we had before where we actually modeled out different scenarios so that as the climate changes, you’re prepared for those changes with different assumptions baked in.

Can you tell us about what are some of the scenarios that Jellyfish evaluated this year, and how did you think about making trade-offs between them?

KK: Trade-off decisions are always in partnership with your finance team. They’re setting the constraints that your budget plan is based on, and their constraints might have to do with your revenue growth projections, your cost basis, and how your costs will be constrained this year. 

When we thought about scenarios, we were modeling out different projections for revenue growth in 2023. From those, you back out, what is the expected expenditure of R& D that you can have given those models? So you have your aggressive growth, your moderate growth, and so forth, and you’re going to put together different headcount plans and different resource plans based on those revenue projections so you can adjust accordingly.

Eli, I’m curious, where do you take it from there? What’s the next step?

ED: So the first thing that we want to know is what are we going to do if we add X number of people in R&D this year? How far do we get and what business outcomes are we achieving with those people? 

The starting point to answer those questions is to think about the current investment today and how much of what we’re doing is discretionary, meaning it’s subject to our own choices that are strategic and we can choose versus how much of it is stuff that we just needed to do in order to keep the business running and afloat.

Obviously, we want for internal efficiency reasons more discretionary and less mandatory, but for planning reasons, you want to be real about where you’re at. As you’re looking into the next year, if you have X amount of capacity working on stuff, we need to know how much of that is just going to get consumed by the day-to-day.

That was a lot of iterating with Krishna and team on models of what is our own “Keeping the Lights On” investment looks like and how we might get more efficient. Also, what capacities do we actually have? For example, if we’re adding 10 new team members to go do something, what does that mean about the amount of capacity that can really be dedicated towards that new something? That enables the discussion team by team of, “If these are our top areas of investment that we want to make, how far could we actually get with three people working on that thing?”

Jeff, it feels like this is the point of the planning conversation where you have discussions on what you’re going to deliver. Can you talk about that and what prioritization and the budget process look like in your role?

Jeff Brainerd, Senior Manager at Jellyfish: One thing to know is that at Jellyfish, we really push down a lot of ownership to the teams themselves, even at the initiatives level. So the next step is really to start to identify and refine the initiatives given the team mission, the business priorities, the budget constraints. Ultimately, we drive toward a team roadmap. That process includes a lot of conversations with engineering leaders, product team members, and of course our own team members.

So what are the changes in this environment of slower or no growth? 

  1. I think efficiency is really now explicitly part of the equation in ways it hasn’t before. For instance, on my team, we think a lot about infrastructure costs, tooling costs, and what investments we can make to enable other teams more efficient and reduce friction in the developer workflows. 
  2. It’s time to be very realistic about your constraints. You may not be able to hire or you may be hiring a lot slower. So you really need a strategy on what makes sense to tackle or defer given the seniority and the skillsets of the people on your team. 

Jeff, how is your team thinking about the balance of “Keeping the Lights On” or work that’s discretionary versus not in this environment? Is that a part of the conversation at the team level as well?

JB: It definitely is. We have a team practice of tracking Investment Allocations. The goal is to drive down unplanned work and to increase the roadmap work. We had the team come up with a KTLO rotation, where one person is fielding unplanned work, which really lets others focus on the roadmap. One thing you can do if that person who’s on rotation is not actively working on a thing that’s come in, they can use that additional time to invest in automation that drives down unplanned work. So I think bringing in the team is really important to get buy-in and to really make that effective for us.

ED: If I can just add on to that: one of the goals that I set with the teams this year was specifically around that allocation fraction of how much effort are we spending in roadmap. Transparently, at the beginning of the year, we were overall, I don’t know, somewhere in the 50% to 60% of our work going on roadmap. The goal for this year was, “No, that needs to be more like 75.” So that was a constraint that Jeff has handed to him is they’re like, “How do we use that capacity that we’ve got more efficiently?” Really, what that means is get distracted less by things that while good to do eventually and hopeful are not actually part of the short-term focus and strategy that we’re doing now. So it’s about discipline and focus on things that really matter the most to us. 

What data is most useful to consider in these discussions?

KK: Eli and I both took a look at the allocation view in Jellyfish and pulled down the headcount allocation for 2022. We took a snapshot actually at Q4 because that represented meeting the hiring plan where everyone was ramped up. We want to see over those three months how we’d actually spent our time as an organization, and that provided the currency by which we did our planning. So we said, “All right. According to this, we had, call it, X allocated headcount per month to use. That’s our baseline going into next year.” So that gave us some ground truth to work from. 

From there, we looked at how that was spent. Eli’s talking about how we were at maybe 50% or 60% roadmap and we want to get that to 75. This is an example of having to shift the balance of where they’re working on because you can’t hire more people.

From that top level view, we drilled into what the KTLO looked like and started to make choices about what we could not do by being more strategic and planning for it in a better way. So we went through and did that analysis of the KTLO work and started talking about where we could make trade-offs, et cetera, but it all started with the Allocation data.

We’ve made investments that are on the roadmap that are focused on reducing KTLO. How do you connect that back to forecasting how much KTLO work is going to happen next year? How do you think about making an assumption given that the product is changing, it’s evolving?

KK: We model out on a per-quarter basis what our ratio would be for KTLO slash unplanned versus planned work. So for example, we modeled that Q1 what looked like last year because we’re making investments in improving the product to reduce escalations in Q1. They wouldn’t pay off right away. So we tried to stagger when we saw the improvements landing on our resource allocation. 

The second bit is we did make some educated guesses about how much the KTLO will go down, based on previous work that will bring down KTLO, and reallocate that to roadmap work. There are swags there, but they’re educated ones based on what we saw as the root causes in the data.

ED: There’s also the ongoing tracking of [how we’re trending against KTLO/Unplanned work] because we’re under no illusions that the budget planning process doesn’t perfectly project everything out. That isn’t the intent; the intent is to figure out macro-level, how are we investing, how many people, in general, do we need, what big themes of work can we pursue, what big goals are we going to be able to accomplish, and know that we’ll have degrees of freedom to flex and adjust as we do it. 

Are we right about how our efficiency efforts are going? How much that particular project is indeed reducing our ability to thrash less? How much team discipline is kicking in? Like the strategies Jeff’s team was applying to reduce thrashing, how do those help with efficiency? So keeping an eye on all these things helps us to see if our estimates are playing out the way that we anticipated.

I’d love to hear a little bit about what are some pitfalls to avoid in this space?

ED: Be really clear in your communication between product development and finance in terms of what the budget numbers mean and to what degree they are a hard line to hit accurately. In project delivery, there’s an operating mode where there’s a hard date and there are external reasons why we need to do it. Come hell or high water, you’re going to hit that date. But that’s a different mode of operation where you maximize for throughput and give date projections, but you can change them as things emerge.

Both of those models can apply to the budgeting process and R&D expenses as well. But it’s really important that everyone is on the same page about what mode you’re operating in. 

KK: It’s not helpful to be overly precise when you’re talking about headcount and allocation. The math will tell you what our estimate was for how many people worked on roadmap and how many people worked on KTLO and how many people worked on escalations, but if you’re like, “I’m going to change that from 75.2 to 74.9 next year,” I don’t think that’s a useful exercise for you. You want to be looking at step function changes and meaningful changes from 75 to 50 or 50 to 25 and then reasoning from there because you don’t know precisely what you’re going to work on at a detailed level anyway. False precision can lead you astray and send you into spreadsheet madness when you really don’t need to be.

ED: That’s true both on relative investment of different teams but also at a specific headcount level because, obviously, part of what goes into this process is some model that goes like, “Oh, we are going to make an investment in area X. Therefore, there’s a team associated with it. Therefore, apparently, I need six engineers, a designer, and a PM,…” and whatever. I’m making some guess about the level of seniority of those people and how much it costs to have them, and that factors into dollar somewhere.”

It may or may not really be true that you want six specific people at on that project. Maybe that project, when you get into it, is better served with a tiger team that’s organized in a different way that’s not the full thing. Maybe it’s bigger or maybe you need a really senior person that’s more expensive. So getting not wedded or overly prescriptively locked into that rigid projecting, while knowing what lines you can’t cross, like your budget limit. 

What’s easier in this environment? Are there any silver linings or opportunities here?

ED: I actually find this environment a lot easier to operate in in many ways. Obviously, it forces hard choices. 18 months ago we were in the world of, “Why not pursue every opportunity? Just hire more people. How hard can that be? Any idea that you have, pursue it. Grow, grow, grow.” 

In contrast, I have clarity in terms of how much we have to spend. If you know you have a weekly budget, you know you can’t spend over X a week. Though, it does force Krishna and I to arm wrestle a little more over exactly which things are in or out. 

KK: Operating constraints are really powerful. It forces the hard choices. It makes us improve the degree of rigor that we’re bringing into our decision making. In more constrained environments, you need to bring more data to your product decisions also. So you need to understand, “Hey, does this capability that we’re talking about help 80% of our customers or 20% of our customers? Is that dollar weighted or is that not dollar weighted?” So the improved decision-making, improved data quality, there is a huge opportunity for all of us to level up and step up our thinking. 

The other big opportunity here is modeling out different scenarios. The scenario planner is a great way to understand what you actually need or don’t need or get input into what you actually need or don’t need. So when you’re having those constrained conversations, and Eli and I are saying, “Hey, this is a four-person investment or this is an eight-person investment,” you can actually look at the data and interrogate that a little bit. It’s not going to tell you the answer because you’re dealing with a non-scoped thing, but in terms of order of magnitude, you can examine what the data looked like historically for your company and model some things out/

JB: On the thread of efficiency as an explicit goal, we found that engineers respond really well to those clear constraints. So on our team, one of the things we’ve been working on is driving down the AWS costs, and that’s a really clear objective, make this number go down. I might go so far as to say that we’ve had fun doing that work. In some sense, efficiency has come in as a mindset. It is a business priority and I feel like folks have really taken it in a way. 

Then the other thing I’ll just say is despite the macro uncertainty, and this gets a little bit to what Eli was saying, on the teams, things feel more stable. We don’t have a lot of new folks joining. The teams are not splitting every three, four or five months, and we’ve found it’s just a great time to level up the team, the execution of the teams. This does not mean we do more work. It means that we do work smarter and better, work better as a team. 

So sometimes that’s just getting back to basics. How can we move faster? How can we provide more certainty to the business like slicing our deliverables small, hitting our target dates because that’s what the business needs right now, it needs more certainty from us, the teams. So those are some of the things we’re thinking about. Just like when the boom times come back, how are our teams going to be better and stronger?

Want to learn more about 2024 Annual Budget Planning? Download the R&D Budget Planning in the Year of Generative AI.