Speed Without a Maintenance Strategy

Your team is shipping faster than ever and delivering less than ever.

That's not a paradox. That's what happens when prototypes silently graduate into production. When "let's just try it" becomes permanent infrastructure. When the thing you built in two weeks takes two engineers to keep alive for two years.

Speed without a maintenance strategy doesn't accelerate delivery. It mortgages it. Your team isn't in a feature factory because they want to be. They're drowning in detail from decisions nobody made on purpose.

Every unplanned product in production is a tax on everything your team ships next.

The Silent Graduation

Nobody holds a ceremony when a prototype becomes a product. There's no announcement, no handoff meeting, no moment where someone says "this is now production software and here's who owns it."

It just... happens.

A stakeholder needed something "by Friday." You built it. It worked. People started depending on it. Now it's in your infrastructure, connected to other systems, generating support tickets. And the engineer who built it is still the only person who understands it — except now she also has her actual roadmap work to do.

I've watched this happen dozens of times. In one case, I built a quick internal dashboard to track a metric our team needed. It took a weekend. Within two months, three departments were using it in their weekly reporting. Within six months, it was breaking every other deploy because nobody had written tests for it — including me. I was spending eight hours a week keeping it alive. Eight hours I wasn't spending on the work that was actually on my roadmap.

That dashboard was never a decision. It was an accident that nobody corrected.

I've seen the same pattern outside tech. A government agency I consulted with had a procurement workflow tool built by a contractor five years earlier. The contractor left. The tool was still running. Three departments depended on it. Nobody knew the codebase. Nobody had budget to replace it. Nobody had authority to shut it down. The old guards and gatekeepers let it linger because decommissioning required approvals nobody wanted to own.

What Maintenance Drag Does to Delivery

Here's the math most teams never run.

When an unowned product enters your portfolio, it doesn't just consume time. It degrades your entire delivery system.

Cycle time inflates. Engineers context-switching between new work and unplanned maintenance move slower on both. I've seen it repeatedly — three unowned products pulling attention from a five-person team can cut effective throughput by a third. Not because the work is hard. Because the switching is constant and the interruptions are unpredictable.

Quality erodes. Maintenance on code nobody chose to own gets the minimum effort. Patches, not fixes. Workarounds, not solutions. Each patch adds complexity. Each workaround becomes a future landmine. The defect rate on orphaned products compounds until something breaks badly enough to force a real response — usually at the worst possible time.

Predictability disappears. When your team can't tell you how much of their capacity goes to unplanned maintenance, every sprint commitment is a guess. Stakeholders stop trusting the timeline. Product reviews become apology sessions. You lose credibility not because your team is slow, but because your delivery cadence is being disrupted by work that isn't even on the board.

Busy teams and effective teams are not the same thing. The difference is usually invisible maintenance.

The Subtraction Problem

Delivery isn't just about what you ship. It's about what you stop maintaining.

Most product organizations have no mechanism for killing things. No retirement process. No sunset criteria. No regular review of "should this still exist?" Features accumulate. Products accumulate. Maintenance obligations accumulate. And nobody with authority ever says "turn it off."

This is the delivery tenet most teams skip entirely: subtraction.

I learned this after running a product audit at a company where engineering kept saying they had no capacity for new work. The numbers said otherwise — they had a full team. When we actually mapped where time was going, 55% of engineering capacity was maintaining products that had no active users, no revenue justification, and no owner. More than half the team was keeping ghosts alive.

We retired four products in one quarter. Capacity didn't magically appear — it flooded back. The team shipped more in the next quarter than they had in the previous two combined. Not because they were working harder. Because they'd stopped carrying dead weight nobody had permission to drop.

Three Numbers That Reveal Your Delivery Health

Maintenance-to-new ratio by team. Not the org-wide average — break it down by team. The team building your core product might be at 25% maintenance. The team that inherited three orphaned tools might be at 70%. The org average hides the teams that are drowning.

Unplanned work percentage. How much of each sprint is work that wasn't on the board at sprint start? Maintenance fires, bug fixes on unowned products, "quick requests" that aren't quick. If unplanned work consistently exceeds 20% of capacity, your team doesn't have a planning problem. They have a portfolio problem.

Time since last product retirement. When was the last time your org deliberately killed something? If the answer is "never" or "I can't remember," your portfolio only grows. That means your maintenance burden only grows. Which means your capacity for new delivery only shrinks. Every quarter you don't subtract, you're choosing a slower future.

The Delivery Test

If you're a PM, not the person running the portfolio: You can still run this on your own work. Pull YOUR last two weeks. Categorize every item: planned new work, planned maintenance, unplanned maintenance, unplanned request. Run the percentages.

If unplanned work plus unplanned maintenance exceeds 30%, your delivery cadence isn't a team problem. It's a portfolio problem. And the fix isn't better estimation or more engineers. It's fewer products — specifically, fewer products that nobody chose to keep alive.

Whether you're running the org or running a single product, the math is the same. Delivery gets better when you stop carrying things you never decided to carry.

Prompt

Map your team's last sprint: what percentage was planned new work versus maintenance on things nobody officially owns? And when was the last time your org retired a product?

Share your ratio — reply with the percentage. I'm collecting these across orgs and the pattern is brutal.

Know a PM who's drowning in maintenance nobody assigned? Send this their way.

Landed here from a friend? Subscribe here.