Feature delivery and paying down architectural debt are competing for the same engineers. How do you decide the split and defend it?

A backlog cannot be prioritised against a roadmap

The reason this argument is usually lost is a category error in how the two sides are presented. Features arrive as outcomes with value attached: this unlocks a segment, this closes a deal, this reduces churn. Debt arrives as a list of tasks: split this service, upgrade that framework, replace the build. One of those can be compared with revenue and the other cannot, so the comparison is decided before it begins, and no amount of insistence about craftsmanship changes it.

The fix is to stop describing debt as work and start describing it as a rate you are already paying. Debt is not the mess; it is the interest the mess charges every month, and interest is denominated in things the business already tracks. How long a change of a given size takes from decision to production. How much of the team's capacity goes to unplanned work. How many incidents originate in the same component. How long a new engineer takes to make a safe change alone. How much of the estate cannot be deployed without coordinating two teams. Those numbers are comparable with roadmap value, and once they exist the conversation is between two investments rather than between commercial reality and engineering preference.

Separate compounding debt from debt that just sits there

Not all of it is worth paying down, and the willingness to say so is what makes the rest of the argument credible. The distinction that matters is whether the cost grows on its own.

Compounding debt gets more expensive the longer you leave it, and the mechanism is usually that more code is being written against it every week. A data model that does not fit the domain acquires new consumers, each one making the eventual change larger. A dependency approaching end of support gets harder to move as versions diverge. A missing test seam means each new feature adds to a manual regression suite that someone runs by hand. These are the ones to fund, because delay is a decision to pay more later.

Stable debt is ugly and does not get worse. A gnarly module nobody touches, an old service that works and receives no changes, a naming scheme that offends everyone and costs nothing. Leaving it alone indefinitely is the correct answer, and putting it on a remediation plan is how remediation plans lose the confidence of the people funding them. Being able to point at something and say you have deliberately chosen never to fix it is worth more to your credibility than any amount of enthusiasm.

The test between the two is empirical rather than aesthetic: look at where change actually lands. Change frequency per component, incident origin per component, and the number of files typically touched by one feature will tell you which parts of the system are load-bearing for delivery. Debt in a component nobody has edited in two years is not costing you anything, however unpleasant it looks in review.

Fund outcomes, not a percentage

The most common proposal is a fixed share of capacity for engineering-led work, and it is popular precisely because it lets both sides avoid the argument. It has two structural weaknesses. It is unaccountable, because nobody has committed to what the share will produce, so it cannot be shown to have worked. And it is the first thing reclaimed under pressure, because a commitment with no named outcome is the cheapest one to break.

The version that survives names the outcome. Rather than twenty per cent for remediation, you commit to reducing the lead time for a pricing change from six weeks to one within two quarters, and you say which specific work does that. Now the funding has a definition of success, and when the busy quarter arrives the conversation is about abandoning a target that somebody agreed to rather than about reallocating unassigned capacity. It also disciplines your own list, because a surprising amount of proposed remediation turns out not to move any metric anyone can name.

How it is framed	Why it gets agreed	Why it fails
Twenty per cent of every sprint for tech debt	Costs nobody a decision	No outcome attached, so it is reclaimed silently in the first crunch
A quarterly remediation epic	Visible in the plan	Competes head-on with features and loses on value comparison
A named delivery metric with the work that moves it	Comparable with roadmap value, and verifiable	Requires the metric to exist and to be believed
Remediation carried inside feature work in the same area	Never needs separate funding	Only reaches the components features happen to touch

The last row is worth defending as a real mechanism rather than a compromise. Much of the highest-value remediation is in exactly the components features keep landing in, so a standing expectation that you improve the area you are changing captures a lot of it without a negotiation. What it cannot do is anything structural that spans components, which is precisely the work that needs the third row.

Stop the debt being recreated

A clean-up with no change to the conditions that produced the mess buys a temporary improvement and destroys your case for the next round, because in eighteen months the same request will be made about the same components and the funder will remember. So every remediation proposal should carry the mechanism that prevents recurrence, and the mechanism has to be automatic rather than cultural.

That usually means something in the pipeline rather than something in a document. A check that fails the build when a new dependency on the deprecated component is added. A ratchet on a metric so that coverage or lint violations cannot get worse even if they are not yet good. Ownership recorded in the repository so that the component has a team, because unowned components are where debt accumulates fastest. Guidance in a wiki page achieves nothing measurable; a failing build achieves the whole thing, and the difference between the two is the difference between a strategy and a preference.

What separates this from a complaint

The answer that lands is the one that arrives having already made the trade-off rather than asking for capacity in general. Bring three items, not thirty, each with the metric it moves, the cost in weeks, and what you will not do this quarter as a result. Say which one you would drop first if the funding were halved, and mean it, because volunteering the sacrifice is what demonstrates you are optimising the business's outcome rather than defending a wish list.

The other half is timing, and it is under-rated. The moment to ask is when the cost has just been felt: the week after an incident traced to the component, the day a commitment slipped because a change took six weeks, the point at which a customer-visible delay has a named cause. Debt funding is nearly impossible to win in the abstract and comparatively easy to win against a specific recent event, so keep the evidence continuously rather than assembling it when you want something. A record of where lead time actually goes, maintained for two quarters, is worth more than any argument you can construct in the meeting.

Express debt as a rate rather than a backlog — lead time, unplanned work, incident origin — and fund only the items that move one of those numbers. Percentage allocations get agreed easily and reclaimed silently; a named delivery target with a ratchet behind it survives the busy quarter.