How to Make the Business Case for Technical Debt

Why technical debt is hard to sell

Before you can make the case well, it helps to understand why the default case fails. Technical debt consistently loses in prioritisation conversations - not because stakeholders are unreasonable, but because the way it is typically presented makes it easy to deprioritise.

The engineers on your team experience debt as friction, slowdown, and dread. Stakeholders experience it as nothing - until it surfaces as a missed deadline, a production incident, or a feature that took three times longer than expected. Your job is to make the invisible visible before one of those outcomes forces the conversation.

Making debt visible: build a debt register

Most teams have a general sense of where the bodies are buried, but that knowledge lives in engineers' heads. It surfaces in corridor conversations and sprint retrospectives, but it never accumulates into something you can bring to a planning meeting. A debt register changes that.

A debt register is a living document that names specific debt items, categorises them by type of impact, and gives a rough size of the cost they impose right now. It does not need to be exhaustive. Fifteen well-described items are far more useful in a prioritisation conversation than a vague list of ninety. Start with the things your engineers mention most often when they talk about what slows them down.

• Velocity dragItems that slow down every sprint without necessarily causing failures. Slow test suites, fragile build pipelines, modules with no clear ownership, workarounds that every developer rediscovers independently. These are insidious because their cost is invisible - the time lost is never attributed to anything, it just disappears.
• Reliability riskItems that increase the probability or impact of an incident. Untested critical paths, unclear failure modes, services that have no alerting. These items have no sprint cost right now, but they will - and the cost will be large and unplanned. A post-mortem that traces an incident back to a known debt item is your strongest evidence for prioritising it.
• Security exposureOutdated dependencies with known vulnerabilities, authentication shortcuts, unvalidated inputs, services with overly broad permissions. These tend to be the easiest to prioritise because the risk is concrete and auditable. Most organisations have policies that require addressing known CVEs within a defined window.

Framing debt in business terms

Once you have a debt register, you have evidence. The next step is translating that evidence into language that lands with stakeholders. Three frames consistently work better than engineering explanations.

• The velocity taxConnect debt directly to delivery speed. "Every sprint, we spend approximately nine hours working around these four items. That is more than a full developer day per sprint - or roughly six weeks per year - that we are not shipping features. If we invested three sprints clearing the two highest-cost items, we would recover that time within four months." Stakeholders understand time. Translate debt into time lost and time recovered.
• The risk frameConnect debt to incident probability and cost. "This item contributed to our last two production incidents. The average incident costs us approximately twelve hours to resolve, not counting customer impact. Addressing this removes that failure mode entirely." Stakeholders who have experienced an incident are especially receptive to risk framing - they know the cost of an unplanned outage goes beyond the engineering hours.
• The opportunity frameConnect debt to a roadmap item the stakeholder already cares about. "We have the payment redesign on the roadmap for Q3. The checkout module carries significant debt that will add four to five weeks to that delivery. If we address it in Q2, the Q3 feature ships on time. If we do not, we are building on a foundation that slows every decision." This frame is particularly effective because it does not ask for extra time - it reframes existing time.

How to prioritise which debt to tackle

Trying to tackle all technical debt at once is how you end up with a long-running refactor that never ships and nobody can explain to a stakeholder. Prioritise using two axes: how much impact the debt has on your team right now, and how close it sits to planned work on the roadmap.

The "tidy as you go" approach - cleaning up debt in the modules you are already working in as part of feature delivery - is underused. It has no pitch overhead, fits naturally into existing sprint work, and compounds over time. If your team has a norm of leaving code in better shape than they found it, a significant proportion of manageable debt resolves itself without ever needing a dedicated sprint.

Reserve your formal pitches for the high-impact items that are not going to get resolved organically. These are the ones worth building a business case around: the debt that sits in the critical path of something important, or the items that carry genuine risk if left untouched.

How to pitch it and win the time

With your debt register, your prioritisation, and your business framing ready, there are five tactics that consistently improve your chances of getting the time.

• Attach to roadmap itemsThe lowest-friction approach. Before a feature is scoped, note any debt items in the relevant area and include them in the estimate. "This feature will take six weeks unless we address the auth module debt first, in which case it takes four." You are not asking for extra time - you are informing a scoping decision. This reframes the conversation entirely and makes the debt cost unavoidable rather than hypothetical.
• Propose a standing ratioAsk for a fixed percentage of sprint capacity for technical health - typically fifteen to twenty per cent. Frame it as maintaining the engine rather than refactoring for its own sake. "I am proposing we reserve two days per sprint for debt reduction. Here is what we will tackle first, and here is how we will measure whether it is working." A standing allocation removes the need to win the argument every quarter.
• Use incidents as anchorsWhen a production incident can be traced back to a specific debt item, that is your strongest evidence. Do not let the connection fade. Capture it in your post-mortem actions, reference it in the next planning session, and create the relevant debt item as a tracked action with an owner and due date. Stakeholders who have experienced the cost of an incident are far more receptive to the argument for preventing the next one.
• Show a velocity trendIf delivery in a particular codebase area has slowed over the past three to six months, and you can connect that to accumulated debt, that trend is more persuasive than any single argument. Plot the evidence. "It took us two weeks to ship the payment redesign last year. The same scope took five weeks this quarter. Here is why." Data that stakeholders can see over time carries weight that a verbal argument rarely does.
• Commit to reporting backStakeholders are more willing to fund something when they know they will hear whether it worked. "I will report back in eight weeks with the before and after sprint velocity on this module, and confirm whether the reliability issue has been closed." This makes the investment feel bounded, accountable, and reversible - exactly the conditions that make it easier to say yes.

The managers who make sustained progress on technical debt are not the ones who win a single big argument. They are the ones who make debt visible consistently, connect it to business outcomes repeatedly, and build a track record of delivering on the time they are given. Once stakeholders trust that debt reduction produces the results you claimed, the next request becomes easier. The goal is not to win one pitch - it is to build a relationship where technical health is part of how your team is understood.