Your technical debt backlog has 127 items in it. Some have been there for three years. Nobody’s quite sure what half of them even mean anymore. When leadership asks what you’re doing about tech debt, you pick something that sounds important and hope for the best.

There’s a better way.

The Problem With Tech Debt Backlogs

Most tech debt backlogs are just graveyards where good intentions go to die. Someone files a ticket saying “refactor authentication service” or “upgrade database version.” It goes into the backlog. Nobody ever looks at it again.

When you do get time to work on tech debt—usually in that optimistic week between finishing one project and starting the next—you’re paralysed by choice. Everything seems important. Nothing has clear ROI. You end up working on whatever’s annoying you personally that week.

That’s not strategy. That’s just organised procrastination.

The Impact-Effort Matrix Lie

The standard answer to prioritisation is the impact-effort matrix. Plot everything on a grid: high impact vs low impact, high effort vs low effort. Focus on the high-impact, low-effort stuff.

Great in theory. Useless in practice.

Because everything is simultaneously high impact (it’s on the list, isn’t it?) and hard to estimate effort for (we’ve never done it before). You end up with a matrix where everything clusters in the “important but complicated” quadrant and you’re back where you started.

A Better Framework

Here’s what actually works. Score each tech debt item on three dimensions:

Risk: What breaks if we don’t fix this? Scale of 1-5.

• 1: Annoyance, nothing actually breaks
• 3: System degradation, workarounds exist
• 5: Production outage or security incident

Frequency: How often does this cause problems? Scale of 1-5.

• 1: Once a year or less
• 3: Monthly
• 5: Daily or multiple times per day

Cost of delay: How much worse does this get if we wait? Scale of 1-5.

• 1: Stays the same forever
• 3: Gets somewhat worse
• 5: Exponentially harder to fix as time passes

Multiply risk × frequency × cost of delay. That’s your priority score.

Why This Works

This framework forces you to be honest about what actually matters.

That legacy authentication service you’ve been meaning to refactor? If it’s working fine, never causes issues, and isn’t getting worse, it scores low. It stays on the list, but it’s not urgent.

The deployment script that fails 30% of the time and requires manual intervention? High frequency problem. Moderate risk (deployments fail, but you can fix it). Low cost of delay (it’s not getting worse). Still scores moderately high because of the frequency.

The database that’s three versions behind and will be unsupported next year? High risk (security vulnerabilities). Low frequency (hasn’t caused problems yet). Very high cost of delay (harder to upgrade the further behind you fall). That scores high.

The Special Case: Developer Productivity

Some tech debt doesn’t cause production issues—it just makes your team slower. The build that takes 20 minutes. The test suite that’s flaky. The documentation that’s wrong.

These are easy to deprioritise because they don’t affect customers. That’s a mistake.

Calculate the time cost. If the slow build wastes an hour per developer per week, and you’ve got ten developers, that’s 10 hours weekly. 500 hours annually. At $100/hour (loaded cost), that’s $50K per year.

Suddenly fixing the build system has quantifiable ROI. You can compare it to other work using actual numbers instead of vibes.

What About Innovation?

Tech debt work competes with new features and innovation initiatives. How do you make that trade-off?

The answer is: you don’t, really. You need both. Technical debt is the tax you pay on past decisions. If you never pay it, it compounds. Eventually the codebase becomes so fragile that new features take forever to ship.

But if you only work on tech debt, you’re not delivering business value. Your company doesn’t make money from clean code.

A reasonable target: 20-30% of engineering capacity on tech debt and platform improvements. Adjust based on how bad things are. If you’re constantly fighting fires, you need more. If the system is humming along nicely, you can get away with less.

The Must-Fix Category

Some tech debt isn’t optional:

• Security vulnerabilities
• Upcoming end-of-support for critical dependencies
• Scalability issues that will cause outages at predictable growth points
• Compliance requirements

These don’t go through the prioritisation framework. They just get done. The only question is when, not if.

Paying Down Debt Incrementally

You don’t need to fix everything at once. In fact, you shouldn’t.

That massive refactor you’ve been planning? Break it into smaller pieces. Can you migrate one service at a time? Can you replace one component while keeping the rest of the system the same?

Incremental paydown has several advantages: you deliver value sooner, you can stop if priorities change, and you learn as you go instead of discovering problems at the end of a six-month project.

It’s also politically easier. Asking for two weeks to improve deployment reliability is more realistic than asking for six months to rebuild the entire CI/CD pipeline.

Making Tech Debt Visible

Leadership needs to understand tech debt in business terms. “The code is messy” doesn’t land. “We’re spending 15 hours per week on manual deployments that could be automated” does.

Translate technical problems into business impact:

• Risk of outages
• Slower feature delivery
• Higher support costs
• Security exposure
• Difficulty hiring (good engineers don’t want to work on terrible codebases)

Track metrics over time. Are deployments getting slower? Is time-to-fix increasing? These trends make the case for tech debt work better than any explanation of architectural patterns.

When to Give Up

Sometimes tech debt isn’t worth fixing. If a system is scheduled for replacement next year, don’t spend three months refactoring it. If a problem occurs once every 18 months and takes 30 minutes to work around, maybe just leave it.

Not everything needs to be perfect. Some technical debt is fine to live with forever.

The trick is being deliberate about that choice instead of just letting things rot by default.

Review and Ruthlessly Cull

Every quarter, review the tech debt backlog. Some items are no longer relevant—the system was replaced, the problem went away, the team that cared left.

Delete them. Keeping them around creates the illusion of a problem that needs solving when really there’s just old tickets nobody bothered to close.

If something’s been on the list for more than two years and never gets prioritised, either delete it or accept that it’s never getting done and delete it anyway.

Actually Doing the Work

Having a prioritised list is useless if you never work on it. Schedule tech debt work the same way you schedule feature work. Don’t wait for “free time” because there’s never free time.

Some teams dedicate one sprint every quarter to tech debt. Some allocate a percentage of each sprint. Some have dedicated platform teams that only work on infrastructure and tech debt.

The approach matters less than the commitment. If tech debt work is always optional, it will always get deferred.

The Long Game

Technical debt is inevitable. Every decision you make today will look questionable in three years. Technologies change. Requirements evolve. The team learns new patterns.

The goal isn’t zero technical debt. It’s manageable technical debt that doesn’t slow you down or create unacceptable risk.

A prioritisation framework helps you make deliberate choices about what to fix, what to live with, and what to actively ignore.

That beats guessing every time.