Technical debt

Technical debt is the implied cost of future rework that comes from choosing expedience now. A controlled amount is a sensible trade. Left unmanaged, the interest (slower delivery, more defects, more toil) compounds until movement stops. The competency is recognising debt for what it is, quantifying its cost in delivery and risk terms, and scheduling its repayment as ordinary work instead of as a crisis or a rewrite. As scope widens, the same disciplines govern debt's larger siblings: systemic risk that no single team can see, the part of the system everyone is quietly afraid to change, and knowledge that lives in one person's head. It matters because debt stays invisible until suddenly it is not, because the case for repaying it is usually made in the wrong terms, and because a manager who cannot price debt will be told the business cannot afford to pay it. The examinations test it through a product partner who wants no slowdown, a senior engineer who proposes the rewrite, a sole expert leaving in two months, and a board that wants to hear the incident will never recur.

1. Distinguish deliberate, prudent debt from reckless mess. Debt taken on knowingly, for a reason and with the cost understood, is a trade. Debt nobody chose is mess with a flattering name, and it is managed differently.
2. Make it visible and price it. Debt is argued in delivery and risk terms ("this module causes a third of our incidents", "changes here take three times as long") and never on aesthetics. Debt that stays invisible gets repaid only after velocity collapses.
3. Prioritise by interest rate. Weigh the impact on delivery and risk against the cost of repayment. The highest-interest debt goes first, whatever happens to be most annoying.
4. Repay incrementally, in the areas you already touch. Continuous repayment alongside feature work beats both the mythical "later" and the big-bang rewrite, which is a high-risk way to re-learn old lessons.
5. Read the systemic signals before any one team's metrics scream. Incident rates trending up across teams, lead times stretching and knowledge concentrating in single heads all justify action at organisational scope before any team asks.
6. Elevate risk to the level that should decide it. When debt threatens the business and product resists any slowdown, the manager stops negotiating capacity team by team. The risk goes to the executive table as a business-continuity decision with priced options. If feature pressure quietly accepts an existential risk, that is still a decision, and a badly made one.

Technical debt began as a metaphor with a clear origin, and a practitioner vocabulary grew up after it. The unit grades it on that basis.

Debt as interest practice

The metaphor was coined in Ward Cunningham, The WyCash Portfolio Management System (1992). Shipping expedient code is like borrowing: it lets you move faster now, and interest is paid on every later change until the principal is repaid. For managers its value is that it turns the cost of expedience into a running cost instead of a one-off. Its limit is that it invites the wrong argument. Not all debt should be repaid, and the metaphor says nothing about which.

The technical-debt quadrant practice

Martin Fowler, TechnicalDebtQuadrant (2009) classifies debt as deliberate or inadvertent, and as prudent or reckless. Deliberate, prudent debt ("we know this is a shortcut, we will fix it after launch") is a sensible trade. Reckless debt is mess. Inadvertent, prudent debt ("now we know how we should have done it") is what learning ordinarily leaves behind. The vocabulary lets a team classify before it argues. Classifying changes nothing on its own; debt management is the visible tracking, priced impact and scheduled repayment built on top of it.

Continuous incremental repayment practice

The discipline of improving the structure of code in small, behaviour-preserving steps as part of ordinary work, in the areas being changed anyway, instead of in a separate rewrite. Martin Fowler, Refactoring: Improving the Design of Existing Code (Second Edition) (2018) gives it its technical form. Its importance to managers is economic. Repayment in areas already being touched costs almost nothing, and a standing share of capacity for the highest-interest debt elsewhere is cheap. The rewrite is the most expensive and riskiest form of repayment there is.

Systemic risk signals practice

This is an organisational-scope practice that the unit treats as central, though it is not a named model. The manager reads signals that no single team can see and acts on them before a team's own metrics force the issue. The signals include cross-team incident trends, stretching lead times, change-failure rates in particular areas, the module everyone avoids, and the one expert who understands a given system. The practice fails when the manager waits for a team to ask.

Elevation to business risk practice

Also not a named model. At executive scope, technical risk is converted into business terms and decided at the level it deserves: platform debt as continuity risk, a vulnerability class as exposure, and priced options with an honest roadmap impact. Its evidence is experiential. Its failure is the most common one at scope, where capacity is negotiated team by team while the organisation accepts an existential risk by default.

The debt register with prices

The team keeps a short list of its significant debt. Each item carries its impact in delivery or risk terms (incidents caused, time added to changes, features blocked) and an estimate of what repayment would cost. The list is the argument. It turns "the code is bad" into "this module causes a third of our incidents".

The touch rule

Any change to an area with known debt repays some of it. The rule is small and continuous, and it keeps the register from growing. It costs almost nothing because the engineer is already working there.

The highest-interest allocation

The standing capacity share from SV-3 Roadmapping goes on the register's highest-interest items, ranked by impact against cost. The most annoying item, the oldest one and the one an engineer most wants to rewrite do not get it.

The rewrite challenge

A proposal to rewrite a working system is treated as a bet and evaluated as one. What would the incremental alternative cost? What evidence says the current system cannot be improved in place? What happens if the rewrite takes twice as long? The incremental path is explored honestly before the rewrite is funded. Most rewrites do not survive the challenge, and the ones that do are worth funding.

The expiring-option review

When the team discovers a departing expert, a fragile vendor or a single point of failure, the response starts that week, with pairing, documentation, shadowing or redundancy. The chance to act cheaply runs out on a known date, and that date is why it outranks most roadmap items.

At team scope the object is the team's own debt and its repayment schedule. The manager keeps it visible, prices it and repays it incrementally. At organisational scope the object becomes systemic debt that no single team owns, along with the risk signals no single team can see. The manager reads those signals early, funds class-level fixes with named owners, evaluates a large refactor on proxy evidence and stages it to prove value, and acts on expiring options as soon as they are found. At executive scope debt is a strategic liability (the platform's runway, the business's exposure) and is decided at the executive table in business terms. Commitments to the board take the form of measurable remediation programmes instead of promises, and resilience is verified instead of assumed. How Judgment Scales sets out the pattern; the architectural decisions that create debt are TJ-1 Evaluating architectural decisions and their organisational consequences.

• Distinguishes prudent debt from reckless mess before arguing about either. team
• Keeps debt visible, with its impact priced in delivery and risk terms. team
• Repays continuously, in the areas already being touched, alongside feature work. team
• Treats a proposed rewrite as a bet and demands the incremental alternative be explored first.
• Failure mode: invisible accumulation until velocity collapses. team
• Failure mode: aesthetic arguments for repayment. team
• Failure mode: the mythical "later". team
• Failure mode: the big-bang rewrite. team
• Reads cross-team risk signals (incident trends, stretching lead times, feared areas, concentrated knowledge) before any team's metrics scream. org
• When debt is slowing delivery and product wants no slowdown, states the honest trade-off with evidence: the pace is borrowed from future quarters, this is the measured cost, and this is the proposal. org
• Evaluates a large refactor with a hard-to-quantify payoff on proxy evidence, then stages and time-boxes it so it proves its value as it goes. org
• Assigns a named owner and a class-level fix when the same gap appears across several teams. org
• Makes knowledge transfer the immediate priority when a sole expert is leaving, because the option expires in weeks. org
• Treats a vendor outage that took down several teams as the discovery of a systemic dependency, and weighs the cost of resilience against the measured blast radius. org
• Funds the department's immune system: testing and continuous integration, observability, blameless reviews, dependency hygiene and continuous refactoring. org
• Failure mode: waiting for a team to ask before seeing the systemic trend. org
• Failure mode: letting "no feature slowdown" stand as a decision nobody made. org
• Failure mode: patching a cross-team finding one instance at a time. org
• Failure mode: discovering the bus factor at the leaving party. org
• Takes debt that threatens the business to the executive table as a continuity decision with priced options, and stops negotiating capacity team by team. exec
• Prioritises a vulnerability class that spans many services as business risk, with explicit capacity and an honest roadmap impact, instead of squeezing it into team slack. exec
• After a major incident, commits to the board a systemic remediation programme with measurable milestones and honest timelines, and never "it won't happen again". exec
• Can show with evidence whether the organisation survives its plausible bad days: single points of failure mapped, degradation graceful, recovery tested, key dependencies bounded. exec
• Personally tracks a short list of risks: platform runway, security posture, reliability trends and concentration risks. exec
• Failure mode: letting product pressure quietly accept existential risk. exec
• Failure mode: promising the board recurrence-free operation. exec
• Failure mode: treating security capacity as something teams find down the back of the sofa. exec
• Failure mode: delegating reliability so completely that the trend arrives as the outage. exec

Expedience versus interest. Taking on debt knowingly is often right, when the launch matters and the shortcut is understood. The trouble is that a future team, often a different one, pays the interest. The judgment lies in writing the loan down so that it gets repaid instead of discovered.

Visibility versus alarm. A long debt register makes a team look as if it is in trouble, while a short one hides the interest. Keep the register honest and priced, and frame it as control: this is what it costs, and this is the schedule.

Incremental versus rewrite. The strangler path is slower to reach a clean state. The rewrite reaches a promise faster and delivery more slowly. The judgment is to demand that the incremental path be explored properly, and to fund the rewrite only when that exploration fails on evidence.

Repayment versus delivery. Every hour spent on debt is an hour not spent on features this quarter, and every hour not spent on debt is borrowed from a future quarter at interest. A stated capacity share resolves this in principle. The hard part is holding to it when a launch is close.

Honesty versus reassurance at the board. After a serious incident the board wants to hear that it cannot happen again, and the honest commitment is a measurable programme with timelines. Reassurance is discredited the moment the next incident happens. The programme is believable because the board can check it.

During sprint planning, a senior engineer proposes to the team's manager that the order-processing service be rewritten from scratch. The service is six years old, written in a framework the team no longer likes, and the source of roughly a third of the team's incidents. The engineer estimates the rewrite at one quarter with three people. The rest of the team is keen. The product partner is not in the room, and the current roadmap assumes the whole team is on features.

The two easy answers are to approve it, because the team is right that the service is a problem and the engineer is capable, or to refuse it, because the roadmap is full and rewrites are dangerous. Neither deals with the real question, which is what the debt costs and what the cheapest way to repay it would be.

The manager starts with the register. The incident data supports the engineer's claim about a third of incidents. It also shows that nearly all of them come from two modules, the inventory reconciliation and the retry logic, and not from the framework. Changes to those two modules take three times as long as changes elsewhere. The rest of the service is old, unloved and rarely touched, with an unremarkable incident rate. The debt is real, priced and concentrated.

The manager then puts the rewrite through the challenge. The incremental alternative is to replace the two modules in place, behind their existing interfaces, with one engineer over six weeks, and leave the rest of the service alone. That addresses the priced cost at a fraction of the price, and reality gets a vote after the first module. The rewrite would replace four years of accumulated edge-case handling in the parts of the service that work, on an estimate that, as DE-2 Estimation, planning, and honest commitments would predict, is the optimistic one. The manager says this plainly, with the numbers, and proposes the incremental path, funded from the team's standing debt share and starting with the reconciliation module.

The senior engineer is disappointed, having wanted the clean system. The manager gives them the lead on the two modules and says what would change the answer. If, once both modules are replaced, the incident and change-time data still point at the service, the rewrite conversation reopens with that evidence. The product partner is told, in exactly these terms, that the team's debt share for the next six weeks is going to the thing that causes a third of the incidents.

The manager does not fund a quarter-long bet on the strength of a capable engineer's enthusiasm. Nor do they dismiss a real problem because the proposed solution was the wrong one.

• SV-3 Roadmapping: the standing capacity share that funds repayment, and the roadmap it competes with.
• TJ-1 Evaluating architectural decisions and their organisational consequences: the architectural decisions that create debt, and the rewrite set against the strangler path.
• DE-4 Managing scope, risk, and dependencies across workstreams: key-person risk and vendor dependency as systemic risk.
• TJ-6 Security, privacy, and compliance as engineering responsibilities: security exposure as debt's sibling, prioritised the same way.
• SV-2 Communicating and partnering across functions: making the case on debt to product and to the board in their terms.

1. What makes debt "prudent", and what repayment pattern beats a rewrite?
   Answer

   Prudent debt is taken on deliberately, for a reason, with the cost understood. Continuous incremental repayment in the areas already being touched, plus a standing share for the highest-interest items elsewhere, beats the big-bang rewrite, which is the most expensive and riskiest form of repayment.
2. How is debt argued to a product partner?
   Answer

   In delivery and risk terms, such as incidents caused, time added to changes and features blocked, and never on aesthetics. The priced register is the argument.
3. A senior engineer proposes rewriting a working system. What is it treated as, and what must happen first?
   Answer

   A bet, and it is evaluated as one. The incremental alternative is explored honestly first (where the debt is concentrated, and what replacing that part in place would cost), and the rewrite is funded only if that exploration fails on evidence.
4. A departing expert holds a legacy system alone. Why does this outrank most roadmap items right now? org
   Answer

   The option to act cheaply, through pairing, documentation and shadowing, expires on a known date. After that, the same knowledge costs an order of magnitude more to recover, if it can be recovered at all.
5. Debt is slowing delivery across the organisation and product wants no drop in feature output. What is your position? org
   Answer

   The honest trade-off, with evidence. The current pace is being borrowed from future quarters; this is the measured cost; this is a proposal for an explicit capacity share aimed at the highest-interest debt. The decision is made consciously, above you if necessary, and is not left to be settled by silence.
6. The board wants assurance that a major incident will not recur. What can you honestly commit to, and why is "never again" disqualifying? exec
   Answer

   A systemic remediation programme with measurable milestones and honest timelines. "Never again" is false, since no system is free of incidents, and the next incident discredits everything else you say.
7. What does an executive keep on a personally tracked risk list, and why not delegate it entirely? exec
   Answer

   Platform runway, security posture, reliability trends and concentration risks. Reliability and technical risk are strategic matters. An executive may operationalise them through others but should never fully delegate them, because the alternative is learning about the trend from the outage.

• Ward Cunningham, The WyCash Portfolio Management System (1992): the debt metaphor and its interest.
• Martin Fowler, TechnicalDebtQuadrant (2009): deliberate or inadvertent, prudent or reckless.
• Martin Fowler, Refactoring: Improving the Design of Existing Code (Second Edition) (2018): incremental, behaviour-preserving improvement as ordinary work.