Most tech debt registers I’ve inherited as a consulting CTO are wishlists. They’re long, well-documented, and nobody is acting on them. The team writes them in good faith. The CIO reviews them quarterly. The CFO never sees a real proposal. Year on year, the list grows and the actual debt stays mostly where it was.

The pattern is so consistent it’s structural. The reason it happens is that tech debt is being treated as a single category when it’s actually four very different categories that need different handling.

The first category is debt that’s actively costing you operating money right now. Slow build pipelines, brittle deployment processes, manual operational toil. This debt is paid in time every week, and the cost is visible if you measure it. It almost always pays back to fix, and the business case is straightforward when you express it as developer-hours-per-week reclaimed. This category should be paid down continuously, out of the platform engineering or DevEx budget, without needing a special debt-reduction program.

The second category is debt that’s a latent risk. Outdated dependencies with known vulnerabilities, end-of-life infrastructure, undocumented systems with single-person knowledge. This debt isn’t costing you operating money right now, but it’s loaded with optionality on a future bad day. The right business case is risk-based: what’s the probable loss if this fails, and what’s the cost-to-fix.

The third category is debt that’s blocking you from doing something the business actually wants. The legacy auth system that prevents the new mobile app. The data model that can’t support the new product line. This category is the easiest to fund, because the business outcome is concrete. The CIO’s job here is to get clear on what business outcome the debt-fix unlocks, rather than letting it be funded as generic “tech debt.”

The fourth category is debt that nobody actually cares about. Code that’s ugly but works. Architectures that are dated but stable. Naming conventions that drift across teams. This category fills tech debt registers and almost never gets fixed, because the business case never resolves. The honest move is to delete these from the register. They’re not real debt. They’re aesthetic preferences masquerading as technical debt.

The triage framework that’s actually worked for me: every quarter, sort the register into those four buckets. Fund category one continuously through the platform team. Fund category two as a defined risk reduction program with a real budget. Tie category three to the business initiatives it enables and fund through those. Delete category four and stop pretending you’ll get to it.

The other piece of this framework that nobody likes is being honest about the debt that’s structural. Some of your tech debt is the inevitable result of decisions that were correct when they were made and have aged out. That’s not a moral failing. It’s how all software systems work. Debt that’s the cost of having shipped something useful is fundamentally different from debt that’s the cost of having cut corners that didn’t need cutting.

CIOs who can articulate that distinction credibly to a CFO get more debt-reduction funding. CIOs who present the entire register as undifferentiated debt and ask for a single big budget to fix it usually get the budget they deserve, which is to say not much.

The actionable advice for any IT leader inheriting a debt situation: triage before you ask for funding. The sorting work is more important than the engineering work, and it’s the work that makes the funding conversation possible.