Paying Down Technical Debt Without Stopping the Roadmap
You run the engineering. The assessment gave you an exposure level and three lines behind it: whether changes reach production when the business needs them, how much of the team's time goes to standing still, and whether anyone can still change the riskiest part of the system safely. You already know most of what is behind those lines. What this article is about is the part that is hard from inside the team: paying the debt down while the roadmap keeps shipping, with a budget that was approved for features.
The rule the whole article rests on: a technical debt project is the one form of paydown that almost never survives contact with a roadmap. It competes for the same people, produces nothing the business can see, and is the first thing cut when a date slips. Everything below is a way to pay debt without asking for that project.
1. Price it in the currency the business uses
The team's list of debt is usually in engineering terms: coupling, the untested module, the framework two majors behind. Nobody outside the team can rank those. Translate each item into one of three costs the business already tracks.
• Delay. Which roadmap item is this debt slowing, and by how much? "The release window costs us
three weeks on every customer-facing change."
• Run cost. How many engineer-weeks a quarter go to this item's maintenance and its incidents?
• Risk. What happens the week the one person who understands it is unavailable?
An item with none of the three attached is not debt the business is paying for. Leave it off the list. What remains is short, ranked, and defensible in a planning meeting.
2. Fund it as a percentage, not a project
Ask for a share of every sprint or cycle, held constant, rather than a block of time. Fifteen to twenty percent is the usual range. The share is spent on the ranked list from section 1, top down.
Why it survives. A percentage never competes with a feature for a slot, so it is never the thing that gets cut. It also compounds: a team that spends a fifth of its time on the ranked list for a year has paid down more than any project that was approved and then cancelled twice.
When it is not enough. When one item on the list is too large to fit inside the share, such as a platform migration. That one becomes a roadmap item in its own right, priced in section 1's currency, and competes for a slot honestly.
3. Pay it down in the path of the roadmap
The cheapest debt to pay is the debt sitting where the next feature is going anyway. Before each roadmap item starts, check the ranked list for items in the same area, and make clearing them part of the item's definition of done. The coupled module gets decoupled as part of the feature that needs to change it.
Why it works. The engineers are already in that code, already re-learning it, already testing it. The marginal cost of clearing the debt is a fraction of what it costs as a separate task.
Where it fails. Debt in areas the roadmap never visits. The reporting layer nobody plans to touch does not get fixed this way, and if it is on the ranked list, section 2's share is what pays for it.
4. Put tests in before anything else
If the assessment showed a manual regression pass before every release, or one or two people who can safely change the riskiest area, tests come before any other paydown. Not full coverage. Characterisation tests: tests that pin down what the system does today, written before anything is changed, so that a change which alters behaviour is caught by a machine rather than a customer.
Why first. Every other item on the list is a change to code few people understand. Without tests, each of those changes carries the risk the assessment measured. With them, the riskiest area becomes an area a second engineer can work in, which is the knowledge line moving.
The trap. Writing tests for the code you are about to rewrite, then rewriting it, then throwing the tests away. Write them against behaviour the business depends on, at the boundary, so they survive the rewrite.
5. Break the knowledge concentration on purpose
One or two engineers carrying the riskiest area is the line that turns a bad quarter into a bad year. It does not fix itself, because the person who knows the area is always the fastest one to give the next change to.
Three things work, and all three cost delivery in the short term. Pair every change in the area for months, not weeks, with the same second person. Route the next change in that area to the second person with the first one reviewing, and accept that it takes twice as long. And write the map: what the area does, what depends on it, what must never be touched without a specific check. A map the original engineer writes in a day saves a new engineer a month.
6. Shorten the path to production
A release window scheduled months apart is not a process decision. It is the debt made visible: the manual pass, the coupled modules and the fear of the riskiest area all add up to "we only release when we have to." Each of sections 3, 4 and 5 shortens the window as a side effect. The thing to do deliberately is to measure it, change to production in days, and report it beside the roadmap so the business sees the debt going down in the one number it feels.
7. When the roadmap has to stop anyway
There is one situation where the rule at the top does not hold: a platform going out of support, a security exposure, or a framework the market no longer hires for. Then the paydown is a roadmap item, and the honest way to get it funded is to price the alternative in section 1's currency. What it costs to not do it, per quarter, in delay, run cost and risk. That number is usually larger than the migration, and it is a number the business can approve.
Which line decides
If Delivery was the worst line, start with sections 4 and 6. If Running cost was, sections 1, 2 and 3. If Knowledge was, section 5 before anything, and section 4 right behind it.
One question to ask yourself
Not "how much debt do we have." The question is: which one item on the ranked list, if it were cleared this quarter, would move the line the business notices? Clear that one inside the share, report what it changed, and the next share is easier to keep.