Your development budget should work like every other line item on the P&L. Here’s why it doesn’t, and what changes when it can.
Every other function in your company has a budget that means something. Sales knows what pipeline costs to generate. Marketing knows what a qualified lead costs. Operations knows what capacity costs to maintain. These budgets are built on forecasts, validated against actuals, and adjusted quarterly with confidence.
Software development doesn’t work this way. In most organizations, the engineering budget is approved based on headcount or a statement of work, spent against a backlog that changes constantly, and reconciled at the end of the quarter with a shrug. The board asks what the spend produced. The answer is a list of features, not a financial return. Nobody can say with confidence what next quarter’s development investment will yield — or whether the current one was efficient.
This isn’t a discipline problem. It’s a forecasting problem. And it’s solvable. (The Forecasting Gap lays out the full thesis.)
Why Development Budgets Break
A budget is only as reliable as the forecast underneath it. When engineering can’t forecast its own output, the budget becomes a ceiling that everyone knows will be wrong.
The typical failure mode looks like this: leadership approves a quarterly engineering budget based on a roadmap. The roadmap was built from estimates. The estimates were produced by the team in a planning session where requirements were incomplete, edge cases were unknown, and the primary input was gut feel calibrated by optimism bias. Work begins. Scope changes. Dependencies surface. Something takes three times longer than expected. By week six, the roadmap is fiction and the budget is a number that was spent, not managed.
The response is usually one of two equally bad options. Either the team cuts scope to stay within budget (which means the business doesn’t get what it planned for), or leadership approves overrun spending (which means the budget was meaningless). In both cases, the next quarter starts with the same ritual: estimate, approve, hope.
The root cause isn’t that teams are bad at estimating. It’s that estimation is structurally unreliable as a budgeting input. Estimates are guesses about effort. Budgets need forecasts about output. Those are fundamentally different things. (Why We Don’t Estimate explains why we stopped trying to make estimation work.)
What a Forecastable Development Budget Looks Like
When delivery is forecastable — when you can predict what will ship, when, and at what cost before the work begins — the entire budgeting conversation changes.
The budget is built from commitments, not estimates. Instead of approving a dollar amount and hoping the team delivers enough value against it, you’re approving a set of specific deliverables, each with a forecasted cost and timeline. The budget is the sum of those commitments. If priorities shift mid-quarter, you swap deliverables in and out and the budget adjusts accordingly. The total spend is known before the commitment is made, not discovered after the money is gone.
Variance becomes manageable. In a traditional engineering budget, variance is discovered at the end of the quarter when actuals are reconciled against the plan. In a forecast-based model, variance is visible in real time because each deliverable has a committed cost. If a deliverable runs over, the firm that made the forecast absorbs the overage — not the client. The budget holder’s exposure is capped at the committed amount.
ROI becomes calculable. When each deliverable has a known cost and a defined business outcome, you can calculate return on investment at the deliverable level. “We spent $15,000 on this feature and it increased conversion by X%” becomes a real sentence, not a hypothetical. Over time, this data compounds into a decision framework: you know which types of deliverables produce the best returns and can allocate future budgets accordingly.
Quarterly planning becomes meaningful. Instead of “here’s our engineering headcount cost and here’s a backlog we’ll try to get through,” the conversation becomes “here are 45 deliverables we’re committing to this quarter, here’s the total cost, here’s the expected business impact of each, and here’s our confidence level based on three years of delivery data.” The CFO can plan around that. The CEO can present it to the board. The product leader can make tradeoff decisions with real numbers.
The Budgeting Problems This Solves
Most of the budgeting pain in software development comes from the same structural gap: you’re asked to allocate capital to a function that can’t tell you what the capital will produce.
The “how much should we spend on engineering?” problem. Without a forecast, this question has no good answer. Companies benchmark against industry averages (15-25% of revenue on R&D) or just carry forward last year’s budget plus a growth factor. Neither approach connects spend to output. With forecastable delivery, the question inverts: “here’s what we want to build next quarter, here’s what it will cost, does the expected return justify the spend?” The budget becomes a function of planned outcomes, not a guess about capacity.
The “we need more engineers” problem. When delivery is unpredictable, the instinct is to add headcount. But as Brooks’s Law demonstrates, adding people to a software project increases communication overhead faster than it increases output. The real issue usually isn’t capacity — it’s flow. Too much work in progress, too many dependencies, too much context switching. A forecast-based model exposes this because throughput is measured directly. If the team delivers 20 items per month with 8 people, adding 4 people and seeing throughput go to 22 makes the problem visible. The budget conversation shifts from “how many people do we need?” to “how do we improve throughput with the system we have?”
The “we’re over budget but we’re not done” problem. This is the most common failure mode and it happens because the original budget was built on estimates that were wrong. In a forecast-based model, each deliverable’s cost is committed before work begins. If the total cost of planned deliverables exceeds the budget, you know before you start — not after you’ve spent the money. Prioritization happens upfront, with real numbers, rather than in a panic at week eight of the quarter.
The “what did we get for that money?” problem. At board meetings, engineering spend is often the hardest line item to justify. The CTO presents deployment frequency, uptime, and sprint velocity. The board wants to know what those metrics mean in dollars. When deliverables are priced individually and tied to business outcomes, the answer is concrete: “We delivered 52 items this quarter at a total cost of $X. Here are the five highest-impact deliverables and their measured business results.” That’s a language the board speaks.
How to Start
If you’re managing an engineering budget today and it feels like guesswork, the path forward isn’t better spreadsheets. It’s better forecasting underneath the spreadsheet.
The first step is understanding your current throughput: how many deliverables does your team actually complete per month? Not planned. Not estimated. Completed. Pull the data from the last 90 days. That number is your baseline.
The second step is understanding your current cost per deliverable. Take your total engineering spend (salaries, tools, infrastructure, contractors) and divide by completed deliverables. That number will be uncomfortable, but it’s real. And it’s the number you need to start managing against.
From there, the budget conversation changes. Instead of “how much should we allocate to engineering?” you’re asking “how many deliverables do we want next quarter, at what cost per deliverable, and what business outcomes do they need to produce to justify the investment?”
That’s budgeting. Everything before it was just allocating money and hoping.
At Nolte, every engagement is priced per deliverable with a committed cost before work begins. The Forecasting Gap explains the model. If you want to see what forecastable budgeting looks like for your product, book a call.