Why Maintenance Eats Your Engineering Budget

Part 3 listed specialist labor as one of six maintenance buckets. This part returns to it, because it is not merely one bucket among six — for most organizations it is the largest, and it is paid in the one currency no budget transfer can replenish: your engineers’ time. The licensing bill is money, and money can be found. Engineering capacity is fixed in the short run, and whatever the legacy system consumes is gone before the roadmap is ever consulted. This is the part of the maintenance bill that quietly decides what your business is capable of building this year.

The audience for this part is the engineering leader who can feel the drain but cannot yet name it on a slide — who knows the team is busy and the roadmap is slipping, and suspects, correctly, that those two facts are the same fact.

Maintenance is paid in capacity, and capacity is fixed

The crucial property of engineering capacity is that it does not scale with willingness to spend. You can authorize more cloud spend tonight; you cannot authorize more senior engineers who understand your system tonight. So when a legacy system demands engineering time to keep running, that time is subtracted from a fixed pool, and what it takes, the roadmap does not get.

This is why the maintenance drain is so much more damaging than its dollar figure suggests. A maintenance cost paid in money competes with other money. A maintenance cost paid in engineering hours competes with the future — every feature, every integration, every improvement the business wanted but could not staff because the staff was inside the old system, keeping it alive. A team fully occupied keeping the lights on has no one left to build the building.

Where the time actually goes

The capacity does not vanish into a single black hole. It leaks through a dozen small holes, each individually defensible, that together drain most of the bucket. On an aging, locked-in system the engineering day fills with:

• Re-deriving behavior nobody wrote down. Before you can change the system safely, you have to reconstruct what it currently does — from the code, from memory, from production logs — because the living spec does not exist. This is paid on every change.
• Working around constraints instead of through them. Platform and middleware lock-in means the clean solution is often unavailable, so engineers build the workaround the system permits rather than the one the problem wants. The workaround is then itself something to maintain.
• Incident response and manual intervention. Brittle systems need babysitting — the month-end job that fails predictably, the manual fix-up nobody has had time to automate. This is capacity spent staying in place.
• Dependency and compliance churn. Keeping an aging stack patched, audited, and barely supported is steady work that produces no new capability — necessary, and entirely consumptive.

None of these is waste in the sense of carelessness. Every hour is spent on something real. That is exactly what makes the drain so hard to attack: there is no lazy team to fix and no single project to cancel. The capacity is being consumed by the condition of the system, distributed across every engineer and every change, which is why it never shows up as a project anyone could choose to stop.

The number behind it

The industry has put a scale on this, and it is large. McKinsey’s 2020 analysis estimated that technical debt amounts to 20–40% of an entire technology estate’s value, and that actively managing it down can free up to 50% more engineering time. That second figure is the one to hold: up to half of engineering capacity, in the estates McKinsey studied, was locked behind the condition of the systems rather than committed to the roadmap — recoverable, but only by paying the debt down.

The technical-debt series develops where this figure comes from and how to read it; the true cost of technical debt is precisely this lost capacity, expressed as an interest rate on every change. For the purposes of the maintenance bill, the point is simpler: a substantial share of your most expensive, least expandable resource is being spent keeping a system alive, and that share grows as the system ages and the skills thin. Use the industry figure to establish that the drain is real and large in general; use your own teams’ time-tracking to establish what it is for you. The first earns the conversation; the second wins it.

Why hiring doesn’t fix it

The natural response to an over-stretched team is to add people. Against legacy maintenance cost, this is the trap that funds the problem it means to solve, for two compounding reasons.

First, every new engineer inherits the same tax. They join the same difficult system, face the same undocumented behavior and the same workarounds, and pay the same surcharge on every change they make. Adding headcount adds capacity and maintenance burden together, so the share of the team free for new work barely moves. You have a bigger team running just as hard to stay in the same place.

Second — and this is where lock-in bites directly — on a stack with skills lock-in, the people you need are the scarce ones. A technology the market is abandoning has a shrinking, aging, expensive labor pool. IBM (reported via Fujitsu, 2020) has reported the average COBOL developer is roughly 58, with about 10% of that workforce retiring each year. You are not hiring into an open market; you are competing for a contracting one, paying a premium, to expand a team whose work is mostly maintenance. Hiring your way out of skills lock-in means hiring faster than the specialists retire, in a pool that is doing the opposite. The math does not close.

The only move that actually returns capacity is to reduce the maintenance burden itself — to make the system cheaper to change, so each engineer’s hour buys more roadmap and less upkeep. That is what modernization is for, and why it is better understood as a capacity investment than a cost.

What the capacity figure doesn’t capture

Two honest qualifications. First, not all of the time a legacy system consumes is recoverable. Some of it is the irreducible cost of operating any system that does this much — a modern replacement still needs on-call, still needs dependency upgrades, still needs incident response. The recoverable capacity is the difference between maintaining the legacy system and running a modern equivalent, not the whole maintenance figure, and a credible case names that difference rather than claiming the full amount back.

Second, the McKinsey range is an aggregate across many organizations, not a measurement of your team. Your locked-up capacity could be meaningfully higher or lower, and presenting an industry average as if it were your local number is the kind of overreach that gets a business case dismissed by the first person who checks. Use the figure to size the question. Then measure your own split — keeping-the-lights-on versus building — and let that number, with its date and its assumptions, carry the weight.

Where this leads

We have followed the maintenance drain through a single engineering team. The same dynamic plays out one level up, across the entire IT budget, where it has a name leadership already uses: keeping the lights on versus innovation. Part 5, Keeping-the-Lights-On vs Innovation Spend, reads the maintenance bill at the level of the whole budget — the ratio that decides how much of your spend points at the future, and what a locked-in legacy estate does to it.