Tech debt is a loan: run the amortization table on one screen

Tech debt is not a moral failing - it is a loan. Every shortcut you shipped bought speed that day and has been charging interest ever since: rework on every change that touches it, minutes added to every deploy, one more way a 2am page can happen.

A register is not a shame list. It is the amortization table: which loans are still charging interest, who holds each one, and what event forces repayment.

The register: one screen, ten rows, six fields.

1. What - one sentence a new hire could find: "payments retry logic duplicated across three services."
2. Where - repo, module. Not a vibe.
3. Interest - how the debt charges you, in units you already track: rework hours per month, minutes added to deploys, incidents attributable to it. This column decides priority.
4. Owner - a name. "The team" owns nothing.
5. Repayment trigger - the event that forces paydown: next feature touching that module, next dependency upgrade, third engineer joining on-call.
6. Size - hours or days, for scheduling. Interest decides priority; size only schedules.

Why the interest column is the whole point: a two-day debt charging four rework hours a month outranks a two-week debt nobody's code touches anymore. If you cannot name the interest, it is a preference, not a debt.

The paydown rule: no refactoring quarter. When the trigger fires - the next feature touches that module anyway - the debt is paid inside the feature PR. Expand first (additive module + parity tests), contract later (delete the old path). The person who touches the debt pays the interest or refinances the loan.

The five traps:

• The graveyard spreadsheet: 100 rows, no interest column, no owners, dies of shame.
• Debt as shame list: use it to win arguments and engineers stop reporting shortcuts - you lose the early warning.
• The big-bang refactor quarter: scheduled away from production pressure, it drifts and gets cut the first busy week.
• Size without interest: a backlog of estimates with no charge rate tells you nothing about priority.
• Ownerless rows: a row without a name is an unpaid loan nobody holds.

Worked example: a nine-person fintech SaaS feared "the payments rewrite" for two years. The register showed the duplicated retry logic charging ~6 rework hours a month plus two near-miss incidents. When the trigger fired (next payments feature), the paydown shipped as two PRs inside the feature work: shared retry module with parity tests, then deletion of the old paths. Nine days added. Zero payment incidents the following quarter - and the register lost its highest-interest row with a receipt.

The full register template (six fields, the interest-measurement cheat sheet, the trigger library, the weekly review cadence) is free on HIVE80lab Ops Notes.

If you want the surrounding kit - incident response plan, severity matrix, post-mortems for a 1-50 person team: the Ops Starter Kit ($14), Vol. 2 ($27), the Ops Mega Bundle (all five kits, $49), and The First 30 Minutes is a free incident quick-start.