Engineering Maintenance as a Function, Not a Fire Drill
Matthew Holmes
July 22, 2026 · // 9 min read
Every engineering organization above roughly two hundred engineers carries the same problem, and almost none of them have named it.
Nobody owns maintenance. CVE patches, dependency upgrades, framework migrations, config standardization, EOL runtime replacements, deprecation follow-ups: this work has to happen, and there’s no function accountable for making sure it does. It falls to whichever team has a fire that quarter, or to a platform team squeezing it between real platform work, or to a security team already buried in actual security work.
Engineering maintenance becomes a function when it has a named leader, a budget line, an explicit backlog, and regular reporting to leadership — the same structure that turned DevOps and Platform Engineering from ad-hoc tasks into funded disciplines. Without that structure, maintenance stays a fire drill: work that happens under duress, after something breaks, an auditor asks, or a security scan surfaces a finding that’s been sitting untouched for eleven months.
That’s a panic response with a recurring schedule.
Why maintenance keeps losing to feature work
Most engineering organizations already have functions that used to be tasks. DevOps moved from an ad hoc task in the mid-2000s to a funded discipline with directors and org charts within about a decade. Platform Engineering made the same jump a few years later, faster the second time because there was already a template to copy. In both cases, work that used to get handled by whoever had spare time got recognized, funded, and given an ownership model. It stopped eating a team’s slack and became planned work the team was chartered to do.
Engineering maintenance is currently a task at most companies. In a few places it’s becoming a discipline. Almost nowhere is it a function yet, and that gap has four specific costs.
Maintenance loses to feature work every time. A team with both maintenance and feature responsibilities will staff the feature work first, because features have stakeholders asking about status and maintenance has a backlog that only surfaces during audits. In quarterly planning, features get the headcount and maintenance gets a promise that it’ll happen when there’s time, which rarely arrives.
The cost is invisible. No line item in an engineering budget reads “30% of engineering time went to maintenance last year.” The cost sits scattered across every team’s own budget, folded into general headcount. Engineering teams at companies running hundreds of repositories routinely spend 20 to 30 percent of their capacity on maintenance that never ships a feature. When a CFO asks what engineering is delivering per dollar, that labor is in the number, but nobody can point to it. You can’t cut a cost you can’t measure.
The work gets done wrong. A dependency upgrade run by whoever has spare capacity this quarter doesn’t meet the quality bar of work owned by a team accountable for the outcome. It gets rushed and leaves debt behind for the next migration to inherit. The backlog doesn’t stay the same size, either. It gets stickier: harder to work through, more expensive to unstick.
Institutional knowledge never accumulates. Every migration lands with a different team and a different half-remembered sense of how the last one went. Playbooks never build up and patterns never get named, so an organization can run its twenty-fifth Python version upgrade and treat it like the first, because no single team has run enough of them to have opinions worth writing down.
Naming maintenance as a function fixes all four at once, because ownership, budget, quality, and institutional memory all depend on the same thing: someone whose job it is to care about this work past the current quarter.
What a maintenance function actually looks like
Structurally, not much different from what DevOps or Platform Engineering looks like once they’re funded. Different in what gets measured and what gets shipped.
A named leader. Director of Engineering Maintenance, Head of Platform Health, whatever your org calls it. Someone whose title makes maintenance their job, who reports to a VP Engineering or CTO, and whose OKRs are graded on maintenance outcomes rather than features they happened to help ship.
A budget line. Maintenance becomes a category of engineering spend with a real number attached, not an estimate scattered across payroll.
An explicit backlog. Every open initiative, CVE remediation, upgrade wave, EOL replacement, framework migration — tracked in the same system as feature work. Not a spreadsheet someone maintains on the side.
Explicit prioritization. There are always more maintenance initiatives than any team can run in parallel. Someone decides what runs this quarter, what waits, and what gets deferred with a documented reason.
Regular reporting. A monthly or quarterly readout: what shipped, what’s in progress, what’s blocked, where the biggest risks sit. Python 3.9 still running in eight services. Ingress-NGINX not yet migrated. Node 20 in twelve production apps.
Tooling investment. Budget for tools that reduce the marginal labor per repo, per initiative, per change — not tools that just make manual work faster to do by hand.
Playbook accumulation. Every completed initiative produces a playbook: what the migration looked like, what went wrong, what changes next time. Playbooks get versioned and reused instead of rewritten from scratch.
How to measure engineering time lost to maintenance
Most companies talk about engineering productivity constantly and maintenance productivity almost never. That’s the gap worth closing first, because the math without a maintenance function is worse than most leaders assume.
Take a framework migration — Spring Boot 3.5 to 4.x. A senior engineer, probably on the platform team, gets nominated to lead it. A week to scope it. A week auditing repos. Three weeks on a pilot. A full quarter running it across the fleet, during which they aren’t doing the platform work that’s their actual job. Meanwhile other teams run their own smaller migrations with their own overhead, the security team runs CVE remediations on a separate track, and the DevOps team standardizes config across services on a third. Every team reinvents the same coordination work in parallel.
Now compare what changes once maintenance is a function. The same Spring Boot migration goes to a team that already has a playbook from the last major framework migration, tooling that cuts the per-repo work, and a catalog that already shows which repos have owners. The estimate drops from a quarter to three weeks. Every other team keeps doing its own work.
The gap isn’t just speed. It’s cost, quality, and legibility together. Leadership can see how much maintenance is happening, decide whether to fund more or less of it, and make a real tradeoff instead of an implicit one.
Why this function hasn’t been built yet
Maintenance isn’t glamorous. It’s not the function a first-time VP wants attached to their name. It doesn’t produce a headline OKR like “shipped v3 of the customer portal.” It produces OKRs like “cut average CVE remediation time from 45 days to 8” and “eliminated Node 18 across the fleet, unblocking the Node 24 rollout.” Those outcomes carry real weight. They don’t make for a keynote.
The leaders who volunteer for this work self-select for people who like doing unglamorous, consequential work. That’s a small pool. Most VPs of Engineering would rather run the group that ships features than the group that keeps the codebase alive.
The other reason is more mechanical: for a long time, the tooling didn’t exist to make maintenance a function you could staff economically. If every initiative required manual, per-repo work across dozens of teams, concentrating that work in one function was structurally more expensive than letting every team absorb it into their own capacity.
That calculation looks different now that automating the mechanical parts of maintenance — dependency bumps, config changes, deprecated API swaps — is realistic. What’s still missing at most companies is the coordination layer that turns those automated parts into shipped, merged changes across every affected repo, and that’s the layer a maintenance function has to build or buy.
In most cases the change itself is already defined and CI already validates it. What’s missing is generating that change across every affected repository and driving each one to a merged PR, instead of a person doing the same task two hundred times by hand. That’s the execution gap Tidra is built to close.
Tidra is an AI coding agent for both implementation and coordination of code changes across your organization. It generates the code for a defined change, proposes it as a diff per repository, and coordinates the work to completion: opening PRs in bulk, tracking merge status, and following up with owning teams from a single dashboard — with every change landing as a PR someone on the team reviews before it merges. The engineer who’d otherwise spend a quarter chasing two hundred repos by hand instead reviews two hundred generated diffs, which is a materially smaller job.
“We can finally tackle the backlog of maintenance work we’ve been putting off for years,” is how a Head of Platform Engineering described the shift after adopting Tidra. Another engineer put the differentiator more directly: “No more spreadsheets, no more chasing PRs — the real value is in the coordination.”
What to ask before your next planning cycle
Three questions surface whether maintenance is already a shadow function at your org, or something closer to a real one.
How much engineering time went to maintenance last year? If nobody knows, that’s the first question worth answering. Even a rough estimate — interviewing five team leads about what share of their engineers’ time went to non-feature work — beats no estimate at all.
Who’s accountable when a Python EOL hits next October? If the honest answer is “the affected teams will handle it,” that’s the shadow-function pattern. A specific person or team as the answer means you’re already partway to a function.
What’s on the maintenance backlog right now? If nobody can answer, the backlog is invisible. If someone can answer but it only lives in a personal spreadsheet, the function already exists informally and just needs funding. If it’s tracked in the same system as feature work, the function is already built.
Maintenance isn’t going away. It grows every year, in every company, as codebases get larger and dependencies multiply. The real variable is whether someone is actively running that work, or it’s just piling up until the next audit forces the issue.
Building the maintenance function at your org? Tidra runs maintenance work as a discipline, not a fire drill: tidra.ai/get-started/