A tech debt backlog is where good intentions go to die. You create a ticket, it gets triaged below every feature request forever, and eighteen months later someone finds a “TODO: refactor this before it becomes a problem” comment from a person who left the company. Stop filing debt into a backlog nobody prioritizes. Track it where it can’t be ignored.

Why the backlog approach fails

A debt ticket competes against features with revenue attached, and it always loses that fight in isolation. It has no deadline, no customer waiting on it, no metric that moves when it’s done. Product prioritization tools are built to rank things by impact, and “this will save us pain eventually” doesn’t score well against “this closes three deals.”

The backlog also grows without bound, because filing a ticket feels like progress. It isn’t. A 200-item tech debt backlog is worse than no backlog — it’s a graveyard that makes the team feel bad every sprint planning without ever getting smaller.

Track it at the point of pain, not in a queue

1. Leave it in the code, with a name and a reason.

// TODO(dave): this retry loop has no backoff, will hammer the API
// under sustained failure. Fix when we add the queue (see #412).

A TODO with a name and a linked issue is searchable (grep -rn "TODO" src/) and shows up exactly where the next person touching that code will see it — which is the only moment it’s likely to get fixed cheaply, as a side effect of other work.

2. Attach debt to the feature it will block.

Don’t track “refactor the auth module” as a standalone item. Track it as a blocker on the next feature that actually needs auth changes: “before we can add SSO, we need to remove the hardcoded session logic in auth.js.” Now it has a deadline, because it’s on the critical path of something with a deadline.

3. Keep a short, visible list — not a backlog — of the debt that’s actively costing you.

One doc, five items max, reviewed monthly, each with a one-line cost: “the deploy script has no rollback, an incident here costs us 40 minutes instead of 4.” If an item sits on that list for three months without being touched, it either wasn’t actually costing anything — delete it — or it needs to become a scheduled task, not a wish.

The rule that actually works

Debt gets paid when you’re already in the file for another reason, or it gets scheduled with a real date. There is no third bucket. “Someday” tickets are how backlogs become graveyards.

If a piece of debt is bad enough to need dedicated time regardless of feature work — a security hole, a scaling wall you can see coming — say that explicitly and put a date on it, the same way you’d schedule a migration. Don’t let it hide in a ticket queue pretending to be prioritized when it never will be.

What “done” looks like

You’ll never get tech debt to zero, and that’s fine — a codebase with zero debt is a codebase nobody is shipping fast in. The goal isn’t elimination. It’s making sure debt that’s actually expensive gets visibility at the moment someone can act on it cheaply, instead of rotting in a list that gets reviewed once a quarter and actioned never.