Quick take
Multiply pain by how often you touch it. Fix the top. Schedule the middle. Ignore the rest guilt-free.
The Problem With “We Should Really Fix That”
At the fintech startup we had a spreadsheet. Forty-seven items on it. Stuff ranging from “our deploy script is held together with duct tape” to “that one table column named data2.” Every retro, someone added more. Nothing came off.
The list was useless because everything on it felt important to whoever wrote it down. No ranking. No shared language for severity. Just a growing monument to good intentions.
So I built a framework. Dead simple. Two numbers.
Two Numbers, One Multiplication
For every piece of tech debt, score two things on a 1-to-5 scale:
Impact – how much does this actually hurt? A 5 means outages, data bugs, or features you literally can’t ship. A 1 means it annoys you when you see it but has zero customer-facing consequence.
Change frequency – how often does someone touch this code? A 5 means daily. A 1 means you forgot the directory existed.
Multiply them. That’s your priority score.
priority = impact x change frequency
- 15-25: Fix this soon. Like, put it in the next sprint soon.
- 8-14: Schedule it. Quarter planning, debt sprints, whatever your cadence is.
- 1-7: Accept it. Seriously. Move on.
Running the Numbers on Real Stuff
I’ll use examples close to what we actually triaged at the fintech startup.
Our user service had no tests and we were shipping changes to it three times a week. Impact 4, frequency 5. Score: 20. Obviously top of the list.
The deploy process was painful and slow. Impact 4, frequency 4. Score: 16. Right behind it.
We had a gnarly payment integration that scared everyone, but we only touched it once a quarter. Impact 5, frequency 2. Score: 10. Scary, but not urgent.
An admin dashboard that loaded slowly? Impact 2, frequency 2. Score: 4. Nobody cared enough. And that was the correct call.
The math removes the emotion. That’s the point.
Not All Debt Ages the Same
This matters and most people miss it. Some debt compounds. Every time you work around the problem, the workaround becomes the new baseline. The next person works around the workaround. You know exactly what I’m talking about.
Other debt just sits there. Ugly, stable, inert. The weird naming convention in a module nobody touches? It’ll be weird next year too, but it won’t be worse.
And some debt evaporates. We had a messy integration with a third-party API we were planning to drop. Spending time cleaning it up would have been pure waste.
When you’re prioritizing, ask: is this getting worse? Compounding debt should jump the queue even if the current score is middling.
Four Ways to Actually Pay It Down
Boy Scout rule. You’re already in the file. Leave it slightly better. Rename that variable. Extract that function. This handles the small stuff and keeps entropy from winning.
Protected time. Block real capacity for debt work. We did one day a week. Some teams do a cooldown sprint after each release. Doesn’t matter what rhythm you pick, what matters is that the time is sacred and not the first thing cut when a deadline looms.
Bundle it with features. If a feature touches a debt-heavy area, pad the estimate to include cleanup. Product managers accept this more easily than standalone debt tickets because the work is tied to something they already want.
Bite the bullet. Some debt needs a dedicated rewrite. A subsystem replacement. A migration. These need a business case, an owner, and a timeline. Not a Jira ticket that says “refactor payments” with no assignee sitting in the backlog for eight months.
Selling Debt Work Upward
Engineers talk about debt in terms of code quality. Leadership doesn’t care about code quality. They care about shipping speed, incident frequency, and hiring retention.
So translate. “This area has no tests and we ship to it constantly, which is why we’ve had three production incidents this quarter” lands differently than “we need to improve test coverage.” Same problem. Different framing.
At the fintech startup I started tying debt items to incident reports. When leadership could see a direct line between a piece of debt and a customer-facing problem, the prioritization conversation got a lot shorter.
Accepting Debt Is a Decision, Not a Failure
Here’s what changed once we had the scoring system: we stopped feeling guilty about the bottom of the list. A score of 4 means you’ve looked at it, evaluated it, and decided your time is better spent elsewhere. That’s not neglect. That’s judgment.
Low-score debt in a system you’re replacing? Ignore it. Cosmetic issues in stable code? Ignore them. Theoretical problems with no evidence of real pain? Keep an eye on them, but don’t burn a sprint.
The Takeaway
Forty-seven items became six that mattered. The rest we either accepted or scheduled for later with clear triggers for when to revisit. The team stopped arguing about what to fix because the math settled it.
Two numbers. One multiplication. That’s the whole framework.