I’ve been on both sides of budget season. The first few times I went through it, I treated it like a tax. Something to get done so I could go back to the actual work. That was a mistake. Budget planning is one of the few moments in the year where you get to decide what engineering will and won’t do, and how much room you’ll have to do it. If you check out, someone else will fill the vacuum, and you’re not going to like the result.

Here’s what I’ve learned, what I wish I’d done earlier, and the mistakes I keep watching engineering leaders make.

What budget planning actually is

It’s the annual operating plan. You’re answering questions like:

• How much money will the company bring in next year, and how much will we spend?
• How many customers, how do we get them, how do we keep them?
• What does engineering need in order to deliver against the company’s goals?

It’s iterative. Your first draft is a starting point. Finance, sales, marketing, and your CEO will all push back, and you’ll do several rounds before anything is final.

A few things that get confused with budget planning but aren’t the same thing:

• Roadmap planning. That’s about what we’ll build. The roadmap and the budget feed each other, but they’re separate processes. Sometimes the roadmap tells you what you need to staff. Sometimes the budget tells you what the roadmap is allowed to be.
• Performance reviews and comp. These cost money, so they touch the budget, but they run on their own track. Major promotions and out-of-band comp changes need to be reflected in your numbers.

How to prepare

Whether you own the whole engineering budget or a slice of it, the work is the same.

Know your people. Who’s on the team today, what each person costs fully loaded, what roles you need to add, and what attrition you’re planning for. If you don’t have a clear answer for “who would you hire and in what order,” you’re not ready.

Know your work. What is the team committed to that’s already on the books? What’s been promised but not staffed? What’s the support and maintenance load that’s going to happen whether you plan for it or not?

Know your costs. People are usually most of it, but not all of it. Recruiting fees. Cloud spend. Tools. Vendor contracts. The free trial that quietly turned into a $40k contract last year. Pull the real numbers from finance, don’t estimate.

Plan for the pushback. You will be asked some version of these questions, and you should have an answer ready:

• “Why can’t your existing team take on more?”
• “What if we offshored some of this?”
• “What would you cut if you only had 80% of this budget?”

If you walk into the room without an answer to the 80% question in particular, you’ve handed the decision to someone else.

Mistakes I keep seeing

Avoiding the process. A lot of technical leaders treat budget season as something to endure. The ones who lean in get more resources, more headcount, and more strategic latitude. The ones who don’t, don’t. It’s that simple.

Forgetting the fixed costs. Most engineering teams I’ve worked with spend more than half their capacity on keeping the lights on. Support, on-call, dependency upgrades, security patches, the slow grind of maintaining everything that already shipped. If you don’t account for that explicitly, finance will assume your team has more headroom than it does, and you’ll spend the year explaining why you couldn’t deliver the new work.

Ignoring last year’s numbers. Review last year’s budget and what actually happened. Where were you off, and why? If you walk into this year’s conversation with an honest read on what went wrong last time and how you’re fixing it, you build credibility. If you don’t, you’ll keep making the same projection errors and losing the same arguments.

Underestimating hiring. Hiring is slow. New people are not productive on day one. If you tell finance you need three engineers and they’ll start contributing in Q1, you’re going to be wrong. Build in the ramp time. Use whatever historical hiring data you have to project when new headcount will actually start contributing, not when they’ll start.

Refusing to estimate. Engineers hate estimating because estimates are wrong. They are. They’re still useful. If engineering won’t estimate, finance will, and finance’s estimates will be worse than yours. Give them numbers, give them ranges, and explain the assumptions.

Treating estimates as the whole story. The mirror of the previous one. Don’t get bullied into smaller numbers without changing the scope or the risk profile. An estimate is a number with a set of assumptions attached. If someone wants the number cut in half, fine, but the assumptions have to change too.

Annual planning isn’t glamorous. It’s also one of the highest-leverage things on your calendar. The hours you put in here will shape what your team gets to do for the next twelve months. If you don’t run the conversation, someone else will, and they won’t have the context to run it well.