Stop ranking tech debt by annoyance. Score it like a portfolio.

Every engineering leader we talk to has a tech debt list. Almost none of them have a tech debt priority. The list is ranked by annoyance: whichever module burned someone most recently floats to the top, and when budget season arrives, the ask sounds like "we need time to clean things up," which is the easiest line item in the company to cut.

The data says this is the norm, not the exception. In Gartner's research on the topic, 44% of organizations name technical debt as a top challenge, yet fewer than 20% of software engineering leaders rate themselves as very effective at managing it. Nearly everyone feels the weight. Almost no one has a system for deciding what to do about it.

The gap isn't awareness. It's that most teams never turn the list into an economic argument.

Score debt on three axes, not one

Gartner's answer is a framework called PAID: plan, address, ignore, delay, from their note "How to Prioritize and Sell Technical Debt Remediation." The mechanics are simple enough to run in a spreadsheet. For each debt item, you score three things on a relative scale:

• Business impact: if this debt bites, what does it actually cost the business?
• Risk: how likely is it to bite, and how soon?
• Remediation cost: what would it take to fix, including labor, licensing, hosting?

Plot risk against impact, size each bubble by cost, and every item lands in one of four quadrants. High risk and high impact means address it now; the fact that it hasn't hurt you yet is a bet you're about to lose. Rising risk means plan it into upcoming work. Low risk and low impact means ignore it, on purpose and in writing. And sometimes the right call is delay: the debt is real, but the engineering effort is worth more somewhere else this quarter.

Two things about this are worth stealing even if you never open the toolkit.

First, ignore and delay are decisions, not failures. Most teams treat every piece of debt as a moral obligation, which is exactly why none of it gets funded. The ask is unbounded. A framework that lets you formally decide not to fix something makes the rest of the list credible.

Second, the scoring only works if the business does half of it. Engineering estimates risk and remediation cost. The business scores impact. The moment a product owner writes down what an outage in the enrollment flow costs in lost revenue, the debt conversation stops being an engineering complaint and becomes a shared liability with a number on it.

Not every fix is a refactor

The other trap is assuming remediation means rewriting. Gartner lists four distinct options, and the cheapest one is the most overlooked: eliminate the application entirely. If a system carries heavy debt and light business value, decommissioning it clears the debt and frees the people. Short of that, you can patch the specific deficiency, encapsulate the mess behind an API so it stops leaking into everything around it, or modernize properly: rehost, replatform, rearchitect, rebuild, or replace.

Encapsulation deserves a special mention because it's the honest middle option. It contains debt rather than reducing it, but containment buys you time and stops the blast radius from growing while you sequence the durable fix. Pretending it's a permanent solution is how you end up with a wrapper around a wrapper. Using it deliberately, as a bridge, is sound engineering.

Sell the impact, not the architecture

Here's where most remediation proposals die: they're written in engineering language. "The codebase needs refactoring" earns a shrug from a CFO, and honestly, it should. It names no consequence. The version that gets funded names what the business loses if nothing changes.

The translation is mechanical once you commit to it. "The build and release pipeline needs updating" becomes "deployment failures are causing outages and features are taking longer to reach production." "Component A is out of date" becomes "we're exposed to a breach through unsupported dependencies, and we can't enter the compliance-gated market until it's fixed." Time, cost, risk, revenue. Those are the four words executives are paid to weigh, and debt expressed in any other vocabulary reads as optional.

Then present options with real trade-offs and let the business choose. This is not diplomacy. Informed consent is what makes the funding stick. A stakeholder who picked encapsulation over a rebuild, knowing the difference, doesn't claw the budget back in month two.

The new deadline: your agents are stuck in the same mud

There's a reason this decades-old problem suddenly has urgency. AI coding tools have repriced technical debt. An agent working in a well-tested, well-bounded codebase is a genuine multiplier. The same agent in your legacy core, where tests are missing, contracts are implicit, and seams are tangled, is useless, or worse, confidently wrong. Teams are discovering that the modules where AI leverage would matter most are precisely the ones where their tools can't operate. The debt that used to tax your engineers now also caps your AI investment, which means the impact score on that quadrant chart just went up across the board.

The Sigao take

Run the scoring exercise, PAID or any honest impact-risk-cost model, before you ask for a dollar. It turns an unbounded cleanup plea into a ranked portfolio with a price on each item, and it forces the business to co-own the priority. That's the difference between debt work that gets funded and debt work that gets deferred until it becomes an incident. This is exactly the shape of our Tech Debt Paydown engagement: evaluate the codebase, map the weak points by leverage, sequence a paydown plan, then pair with your teams to execute it while you keep shipping. And if you want the other half of the argument, the annual dollar cost of leaving the list unfunded, the Technical Debt Cost Calculator below turns eight estimates into that number in about three minutes.

Sources

• Gartner, "How to Prioritize and Sell Technical Debt Remediation": the PAID model, the four remediation options, and the adoption statistics cited above (full note behind Gartner's subscription).