Every technology leader knows the fix is cheaper than the fire. Almost none of them act on it, because the fire is invoiced in currencies that never show up on a budget line: hours, attention, and the strategic work that quietly stopped being scheduled. Firefighting feels free, but that is exactly why it is the most expensive thing a mid-sized tech function does. Let’s put the economics plainly, because “invest to save” is a tired line and this is a sharper claim than that.

Firefighting is a recurring tax, not a one-off cost

A fire has an obvious price: the engineer’s afternoon, the delayed release, the apology to the business. Leaders see that price, wince, and move on. What they miss is that the same fire will bill them again next month, and the month after, because nobody addressed the fragile dependencies that started it.

That is the difference between firefighting and fixing. The fix is a one-off cost, but the firefighting ends up being a subscription. You pay it every cycle, forever, and the amount goes up as the estate ages and the workarounds pile on top of each other. A function at the typical 80/20 run/drive split is not paying that tax occasionally, it is paying it as a function of the main line of business.

Run the arithmetic over a year and the recurring cost of not fixing dwarfs the one-time cost of fixing almost every time. The reason it does not feel that way is that the tax is paid in capacity, and capacity does not appear on the invoice.

The compounding cost nobody prices in

Every fire fought without a fix leaves the estate a little more fragile than before. A quick patch becomes a permanent dependency, and each workaround becomes more load-bearing. The next fire is more likely, harder to trace, and more expensive to put out, because it now sits on top of six earlier ones nobody had time to clean up. The team gets better at firefighting, which feels like progress but is actually the trap tightening, because skill at the fire is not the same as absence of the fire.

Meanwhile the drive work starves, but not in a dramatic fashion, it happens quietly. The strategic initiative slips a quarter, then stops being scheduled, because everyone has learned it never survives the week. That is a real cost too, and it is the largest one, even though it never generates a single ticket.

Why the fix keeps losing the argument

If the fix is so obviously cheaper, why does firefighting keep winning? Because the two costs are visible at different times and to different people.

The fire has a clock on it and a name attached: an outage, an angry business unit, a deadline. The fix has neither. It is unglamorous structural work, integrations rationalised, dependencies retired, an estate properly configured, the kind of work that rarely makes it onto a roadmap because nothing breaks the day you skip it. So the fix loses every prioritisation meeting to whatever is on fire right now, and it loses it every single time, which is precisely how a capable function stays stuck for years.

Breaking that pattern is not about working harder on the fires. It is about protecting enough capacity to do the fix while the fires are still burning, which no team at 80/20 can do without help, because the run reclaims every freed hour before it can be spent on prevention.

So what should you actually do?

Stop asking what the fix will cost and start asking what the fire is already costing you, annualised.

Pick your three most frequent recurring incidents. Estimate the hours each one consumes per month, multiply by twelve, and add the strategic work those same hours would otherwise have funded. In our experience that number is large enough to reframe the whole conversation, because it makes the recurring tax visible for the first time. Then compare it to the one-off cost of removing the underlying cause. The fix almost always wins on the numbers. It only ever lost on the timing.

The fire that keeps coming back is not bad luck. It is an unpaid invoice for a fix you have been deferring, and deferral is not free. It is the most expensive option on the table.