Quick take
Stop pretending tech debt will fix itself. Put it in a registry, score it, and schedule it like real work. We did this at the fintech startup and it turned a chaotic backlog of “we should really fix that” into something we actually ship against every sprint.
Every engineering team I’ve worked with has some version of the same conversation. Someone mentions a gnarly part of the codebase. Everyone nods. Someone says “we should really clean that up.” Nobody does.
At the fintech startup, we hit a point where this was genuinely hurting us. Our fintech data pipeline had accumulated enough shortcuts and half-finished migrations that feature work was getting slower every quarter. Not dramatically. Just enough friction that estimates kept creeping up and nobody could point to exactly why.
So I built a system for it. Nothing fancy. But it changed how we think about debt.
What tech debt actually is
Tech debt is a future cost you created with a present decision. Sometimes that decision was smart – you shipped faster and the tradeoff was worth it. Sometimes it was accidental – the design was fine until requirements shifted. Either way, the cost is real.
The forms we see most often:
- Deliberate shortcuts. You knew it was a hack. You shipped anyway. Fair enough.
- Accidental debt. Looked fine at the time. Scale or new requirements proved otherwise.
- Environmental shifts. A dependency gets deprecated. A compliance rule changes. Not your fault, still your problem.
- Operational gaps. Missing monitoring, thin tests, no runbook. The kind of thing that bites you at 2am.
Our debt registry
Here is what actually worked for us. We created a debt registry – basically a shared list of known liabilities that lives right in our issue tracker. Not a separate doc. Not a wiki page nobody reads. Same board, same sprint planning, same visibility as feature work.
Each entry looks roughly like this:
id: TD-021
title: Legacy auth flow lacks rate limiting
area: auth-service
impact: Security, reliability
risk: High
effort: 3-4 weeks
owner: Platform
status: Proposed
The key insight was treating debt entries as first-class work items. When debt lives in a separate spreadsheet, it gets ignored. When it sits next to feature tickets in the same planning session, it gets discussed.
We review the registry every two weeks during sprint planning. Takes ten minutes. That alone changed how we worked.
Scoring: keep it dead simple
We tried complex scoring matrices. They didn’t survive contact with reality. What stuck was three dimensions and a formula you can do in your head:
- Impact. How much does this slow us down or degrade the product?
- Risk. What happens if it gets worse or fails outright?
- Effort. How much work to fix it?
priority = (impact * 2) + risk - effort
Each on a 1-5 scale. Is it perfect? No. But it forces you to compare things that otherwise feel impossible to rank. “The auth system is scary” versus “the build is slow” suddenly becomes a conversation with numbers instead of gut feelings.
When to act now versus later
Some things can’t wait:
- Security exposure. Full stop.
- The same root cause behind repeated incidents.
- A dependency about to hit end-of-life.
- Workarounds that tax every single release.
Everything else goes into the prioritized backlog. High impact, low effort items get picked up opportunistically. Large refactors get scheduled as dedicated work with clear milestones.
How we schedule paydown
We tried three approaches before settling on a hybrid:
Capacity allocation. We reserve roughly 20% of each sprint for maintenance and debt work. Non-negotiable. Product knows about it. This is the baseline.
Debt sprints. Every six weeks, we run a focused sprint on the highest-priority debt items. Engineers pick from the top of the registry. These sprints have been some of the most satisfying work the team does.
Opportunistic paydown. If you’re already in the code, improve it. Boy scout rule. We just ask people to tag the cleanup commits so we can track the effort.
Incremental migration over big rewrites
We learned this the hard way. Big-bang rewrites fail. They just do. Every large debt item at the fintech startup now follows the same pattern:
- Run old and new paths in parallel.
- Migrate the highest-traffic paths first.
- Set a cutover date. Remove old code on that date. No exceptions.
Feature flags make this safe:
if flags.new_auth_flow:
return new_auth.authenticate(user)
return legacy_auth.authenticate(user)
The flag gives you a kill switch. Sleep better at night.
Selling debt work to non-engineers
This is where most teams fail. You can’t walk into a planning meeting and say “the auth code is messy.” Nobody cares.
What works: translate debt into business language. “Feature X takes twice as long to ship because every change requires manual regression testing in the auth module.” Now it’s a delivery speed conversation. Product managers understand delivery speed.
At the fintech startup, we started including debt impact in our sprint velocity reports. When the team could show that velocity dropped 15% quarter-over-quarter and tie it to specific debt items, getting time allocated stopped being a fight.
Prevention
A few guardrails go further than any cleanup sprint:
- Lightweight design reviews for anything touching critical paths.
- Code review checklists that ask about maintainability, not just correctness.
- Quarterly dependency upgrades so you never face a multi-year jump.
- Documentation expectations for anything another team will touch.
Closing
Tech debt isn’t a failure. It’s an accounting problem. You took a loan, now you need a repayment plan.
The registry changed everything for us. Not because it was sophisticated – it was a handful of fields in Jira. But because it made invisible costs visible. And once everyone can see the cost, the conversation about paying it down gets a lot easier.