Make Dull Work Visible: The Case for a Maintenance Budget

Every sprint has a leaderboard. There is the feature work that gets demoed on Friday, the bug fixes that get a mention in retro, and then there is the quiet pile of work that keeps the product from falling over. Dependency bumps. Certificate renewals. Test suite repairs. A database upgrade that has been 'next sprint' since the last time someone had a free afternoon. None of it looks like progress on a roadmap, which is exactly why it keeps losing to whatever shiny thing arrived in the team chat.

That is the case for a maintenance budget: a protected slice of sprint capacity, agreed in advance, for the unglamorous work that keeps existing systems healthy. Not a vague promise to 'make time'. Not a heroic Friday afternoon. A line item. In UK teams, where delivery pressure is real and headcount is rarely generous, making that work visible is less about process and more about honesty.

The invisible queue

Maintenance is invisible because it succeeds quietly. Nobody notices the patched library, the renewed certificate or the flaky test that was fixed before it became a three-day investigation. They notice the outage. They notice the security finding. They notice the release that slipped because a framework upgrade turned into a fortnight of surprise archaeology.

When maintenance has no budget, it becomes a series of tiny loans against future delivery. A developer skips the dependency update to finish a ticket. A team defers the observability work because the dashboard is 'good enough'. Someone adds a note to the backlog: 'revisit after launch'. The note ages badly. The cost does not disappear; it moves to the least convenient moment, usually a Friday afternoon before a bank holiday.

What novelty costs

I have watched teams switch from a stable, well-understood stack to a newer one because the conference talks were better. Sometimes that is the right call. Often it is not. One team I worked with moved a perfectly ordinary web application onto a more fashionable framework and spent two quarters rebuilding basic things they already had: authentication, permissions, deployment scripts, accessibility fixes. The old system was not beautiful, but it was understood. The new one was exciting, and it was late.

Another common pattern is replacing a boring but reliable tool with a more complex one because the team wanted to feel modern. The result is not always a disaster, but it is almost always a new maintenance bill: more moving parts, more dashboards, more things that need upgrading on a schedule nobody owns. Proven technology is not automatically good technology. But 'proven' is a feature, and it deserves a budget line just as much as 'new' does.

The pitch: insurance, not nostalgia

The trick to pitching a maintenance budget is to avoid sounding like the person who wants to ban all change. You are not arguing against innovation. You are arguing for the capacity to adopt new things deliberately and retire old things safely. Frame it as risk management and delivery predictability, not as a plea for quieter times.

A simple proposal for a stakeholder conversation:

• Ask for a fixed share of capacity. Start with 15% of sprint capacity, or roughly one day in a five-day sprint. Make it visible on the board rather than buried in tickets.
• Define the scope. Dependency updates, security patching, certificate renewals, test suite health, runbook updates, accessibility fixes, performance work and incident follow-ups all count. So does time spent evaluating whether to remove something.
• Set guardrails. This is not a dumping ground for every unfinished idea. The maintenance backlog should be reviewed monthly and prioritised against risk.
• Name the measures. Fewer emergency patches, shorter incident recovery, lower dependency lag, fewer 'we cannot upgrade because...' conversations. Keep it small and honest.
• Report back. If the budget is consistently unused, say so and return capacity to feature work. If it is consistently overrun, that is evidence you need more, not less.

The language matters. 'We want to spend 15% of our time on maintenance' can sound like a luxury. 'We want to reserve 15% of capacity to reduce release risk and keep our security posture current' sounds like management. Both describe the same work. One is easier to approve.

What goes in the budget

The contents will vary by team, but a useful starting list looks like this:

• patching operating systems, runtimes and libraries;
• upgrading databases, queues and other infrastructure with a supported lifespan;
• fixing tests that are slow, flaky or simply absent;
• updating runbooks, diagrams and on-call notes;
• removing dead code and unused services;
• paying down accessibility and performance debt that affects real users;
• investigating recurring alerts before they become incidents.

That list is not glamorous. It is also not optional. A boring technology budget is simply the cost of keeping your innovation from becoming someone else's legacy. The alternative is a team that ships quickly for a while and then spends months paying interest on the shortcuts.

Keeping it honest

A maintenance budget can become a slush fund if nobody watches it. Publish the list. Review it in the same way you review feature work. Ask whether the work actually reduced risk, or whether it was just comfortable tinkering. If the same upgrade appears for three sprints running, that is not maintenance; that is a project that needs its own plan.

There is also a cultural benefit. When dull work is budgeted, it stops being invisible labour. The person who updates the dependencies is not interrupting the 'real' work; they are doing the real work. In UK engineering teams, where we often talk about craftsmanship and sustainability, that distinction matters. Clean builds are not just about tidy code. They are about giving the unglamorous parts of the job a proper seat at the table.