Debt Register
A maintained record of known technical compromises with their cost, impact and repayment trigger, making debt manageable rather than merely felt.
Technical debt that is not recorded is not managed. Its interest is paid silently as declining delivery speed that nobody can attribute, and the argument for repaying it becomes a matter of who complains most persuasively.
A useful entry states: what the compromise is, why it was taken (deliberate debt for a market window is different from debt from carelessness), what it costs now — ideally in terms someone outside engineering can evaluate, such as lead time or incident frequency — the estimated repayment cost, and a trigger for when it must be repaid.
The trigger is what converts an item from a wish into a plan: "before onboarding the second tenant", "when this exceeds 1,000 requests per second", "at the next major version upgrade".
Two distinctions the register should make visible:
Deliberate versus accidental. Both slow future change; only the first was a decision, and only the first can be defended.
Local versus architectural. A badly written function is an afternoon. Architectural debt — a wrong boundary, a shared database, a data model — charges interest on everything and repaying it means a migration. The two should not sit in the same priority list without that distinction being obvious.