Technical Debt Management Framework

The series so far has been diagnostic. We can define debt, locate it, trace its causes, price its cost, and measure it. Part 7 closed the measurement arc. And measurement is where most organizations stop, which is why most organizations stay in debt. A dashboard of accurate metrics changes nothing on its own. The work is turning those numbers into decisions, repeatedly, inside how the organization actually runs.

That is what a technical-debt management framework is: not a one-time cleanup project but an operating system for debt. The right mental model is maintenance, not surgery. You do not “finish” managing debt any more than you finish maintaining a building. You establish a discipline that keeps it controlled while you keep using the building. This part lays out that discipline in five components.

The goal is control, not zero

Before the components, the target. The aim of debt management is not zero debt. Part 1 established that deliberate debt is sound leverage, and Part 3 established that several causes of debt are inherent to building software that lasts. A team chasing zero debt is over-engineering. It pays principal on debt that charges no interest, while delivery starves.

The goal is debt held at a deliberate, sustainable level: low enough that the interest does not strangle delivery, taken on consciously where it buys real speed, and repaid before it compounds out of reach. Control, not elimination. Every component below serves that target.

The five components at a glance

Component	What it is	The failure it prevents
1. Make debt visible	A living debt register of the items that charge real interest	Managing debt you cannot see
2. Prioritize by interest rate	Repay where high change-frequency meets high pain	Polishing ugly code nobody touches
3. Fund the repayment	A standing, protected allocation of capacity	The boom-bust emergency cleanup
4. Govern new debt	Every shortcut recorded as it is taken	Silent accumulation outpacing repayment
5. Review the trend	A regular check that repayment keeps pace	The framework decaying into a binder

The five are a cycle, not a checklist you complete once. The sections below build each one in turn, and the closing section shows how they feed each other.

Component 1. Make debt visible

Debt that no one can see cannot be managed, and Part 4 showed that debt’s defining property is invisibility. So the first component is a durable, shared view of the debt. That is Part 5’s triangulated picture, kept current and kept where decisions are made.

Concretely, a debt register records known debt items: what they are, which type (Part 2), where they live, and an estimate of their interest (how much they slow work, how often that work happens). It is fed by the qualitative signals, code metrics, and delivery data of Part 5, and it sits in the same backlog as features, not in a separate document that goes stale. The register is not a wishlist of every imperfection, which would just be noise. It is the inventory of debt that charges meaningful interest, the candidates for repayment. Visibility is the precondition for everything that follows. Without it, the other four components have nothing to act on.

Component 2. Prioritize by interest rate

With debt visible, the question is what to repay first. This is where most frameworks go wrong, by prioritizing the biggest or ugliest debt. The correct lens, set up across Parts 4 and 6, is the interest rate: repay the debt that costs the most per unit of work, which means the intersection of high change-frequency and high pain.

A simple, defensible ranking:

Change frequency	Pain to change	Priority
High	High	Repay first: highest interest, paid constantly
High	Low	Watch: cheap now, but a candidate if pain rises
Low	High	Repay opportunistically, only if you must touch it
Low	Low	Leave it: charges no interest, repaying is waste

The bottom-left cell is the discipline most teams lack: leave the ugly code nobody touches alone. It offends the engineer’s sense of order and it costs nothing, and spending repayment capacity there is the over-engineering this framework exists to prevent. The top-left cell, code you change constantly that is expensive to change, is where repayment compounds in your favor, because every future change to it gets cheaper. Prioritization is the difference between a debt program that pays for itself and one that polishes corners.

Component 3. Fund the repayment

A priority list with no capacity behind it is a wish. The third component is a standing, protected allocation of engineering capacity to debt and maintenance, set as a fixed fraction of every cycle rather than a leftover.

A widely cited practice is to dedicate on the order of 15 to 20% of capacity to debt and maintenance work. The specific percentage matters far less than two properties: that it is consistent and that it is protected. Consistency turns repayment into a steady force that keeps pace with accumulation. Protection means the allocation survives a deadline crunch rather than being the first thing sacrificed, and that is what prevents the failure mode this whole framework guards against: the boom-bust cycle, where debt is ignored under pressure until it forces an emergency rewrite, which is the most expensive way debt is ever paid.

The economic argument for the allocation is the one Part 4 made: an organization losing a large fraction of its capacity to debt interest is already spending far more than 20% on debt, just chaotically, as friction, instead of deliberately, as repayment. The allocation does not add cost. It redirects a cost you are already paying toward actually reducing the principal. We develop this argument for leadership in Part 11.

Component 4. Govern new debt

The first three components manage the debt you have. The fourth stops you from silently adding more, because a framework that only repays while accumulation runs unchecked is bailing a boat with a hole in it.

Governing new debt does not mean forbidding it, which would contradict Part 1. It means making new debt deliberate and recorded rather than reckless and invisible. It moves debt out of Fowler’s reckless-inadvertent quadrant and into the deliberate-prudent one (Part 2). In practice:

• When a shortcut is taken to ship, it goes into the debt register as it is taken, with a note on why and a rough repayment intent. The borrowing is conscious and visible, never silent.
• Code review and standards catch the reckless, inadvertent debt, the kind from skill gaps and missing standards (Part 3), before it lands.
• A “definition of done” that includes tests addresses the test debt that Part 2 identified as the force multiplier, keeping the safety net intact so future repayment stays cheap.

The principle is simple: it is fine to borrow, as long as you write down the loan. Governance is what keeps the debt register honest and keeps tomorrow’s debt from being a surprise.

Component 5. Review the trend

The fifth component closes the loop: a regular review of the debt trend that feeds back into the first four. Monthly or quarterly, the leadership and engineering teams look at the same picture. Is total debt rising or falling relative to delivery? Is the allocation keeping pace? Are the highest-interest items getting repaid? Is new debt being recorded or sneaking in?

This review is what makes the framework an operating system rather than a binder. It is where the trend data from Part 5 earns its keep, where the priority list (Component 2) gets re-ranked as the codebase and roadmap shift, and where the allocation (Component 3) gets adjusted if debt is outpacing repayment. It also creates the shared visibility between engineering and the business that the business case depends on. Debt stops being an engineering complaint and becomes a governed metric the organization watches together.

The framework as a whole

The five components form a cycle: visibility feeds prioritization, which directs funded repayment, while governance controls new inflow, and review tunes all four against the trend. Run continuously, it holds debt at the deliberate, sustainable level the framework targets, with accumulation and repayment in rough balance and the highest-interest debt steadily cleared. This is also exactly the discipline that, scaled up across a whole estate, becomes a modernization roadmap: a structured, prioritized, incrementally funded program to pay down debt that has compounded into legacy.

Where frameworks actually fail

A framework is only as good as the organization’s willingness to protect it, and that is where most fail. Not in design but in the first hard quarter. The protected allocation is protected right up until a launch slips, and then it is the first thing cut, and the boom-bust cycle resumes. No framework survives an organization that fundamentally will not fund repayment. The structure cannot manufacture the commitment. There is also a real risk of process for its own sake, a debt register so elaborate that maintaining it becomes its own debt. Keep the framework as light as it can be while still doing the five jobs. The test is simple: if the framework is generating documents instead of changing what the team repays and what it ships, it has become the thing it was meant to prevent.

Where this leads

We now have the operating system: how to track, prioritize, fund, govern, and review debt. What the framework directs but does not detail is the actual repayment. How you pay debt down in a running system without halting delivery or betting the business on a rewrite. Part 9, How to Reduce Technical Debt, gets hands-on with the concrete techniques for clearing debt while the system keeps serving production: refactoring behind tests, the strangler pattern, and incremental replacement.