Technical debt

Technical debt is the implied cost of future rework from choosing expedience now. A controlled amount is a sensible trade; 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 rather than as a crisis or a rewrite. The same disciplines govern debt's larger siblings as scope widens: the systemic risk no single team can see, the area of the system everyone quietly fears to change, the knowledge that lives in one head. It matters because debt is invisible until it is not, because the arguments for repaying it are usually made in the wrong terms, and because the manager who cannot price debt will be told that the business cannot afford to pay it. The examinations test it through the product partner who wants no slowdown, the senior engineer who proposes the rewrite, the sole expert leaving in two months, and the board that wants to hear the incident will never recur.

1. Distinguish deliberate, prudent debt from reckless mess. Debt taken knowingly, for a reason, with the cost understood, is a trade. Debt nobody chose is just 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" — never in aesthetics. Invisible debt is repaid only after velocity collapses.
3. Prioritise by interest rate. Impact on delivery and risk against cost of repayment. The highest-interest debt goes first, whatever is most annoying.
4. Repay incrementally, in the areas you already touch. Continuous repayment alongside feature work beats 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, knowledge concentrating in single heads: these justify action at organisational scope before a 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 and takes the risk to the executive table as a business-continuity decision with priced options. Letting feature pressure silently accept an existential risk is a decision, made badly.

Technical debt has a clear origin as a metaphor and a practitioner vocabulary that followed; the unit grades it accordingly.

Debt as interest practice

The metaphor as coined in Ward Cunningham, The WyCash Portfolio Management System (1992): shipping expedient code is like borrowing — it lets you move faster now, and the interest is paid on every subsequent change until the principal is repaid. Its value for managers is that it makes the cost of expedience a running cost rather than a one-off, and 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

The classification in Martin Fowler, TechnicalDebtQuadrant (2009): debt is deliberate or inadvertent, and 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 the ordinary product of learning. The vocabulary is what lets a team classify before it argues; the classification changes nothing by itself, and debt management is the visible tracking, priced impact and scheduled repayment built on top.

Continuous incremental repayment practice

The discipline, given its technical form in Martin Fowler, Refactoring: Improving the Design of Existing Code (Second Edition) (2018), of improving the structure of code in small, behaviour-preserving steps as part of ordinary work, in the areas being changed anyway, rather than in a separate rewrite. For managers its importance is economic: repayment in the areas already being touched is nearly free, and a standing share of capacity for the highest-interest debt elsewhere is cheap, while the rewrite is the most expensive and riskiest form of repayment there is.

Systemic risk signals practice

Not a named model but the organisational-scope practice this unit treats as central: reading the signals no single team can see — cross-team incident trends, stretching lead times, change-failure rates in particular areas, the module everyone avoids, the expert who is the only one who understands a system — and acting on them before a team's own metrics force it. Its failure is waiting for a team to ask.

Elevation to business risk practice

Not a named model but the executive-scope practice of converting technical risk into business terms and getting it decided at the level it deserves: platform debt as continuity risk, a vulnerability class as exposure, priced options with honest roadmap impact. Its evidence is experiential and its failure is the most common one at scope: capacity 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 with its impact in delivery or risk terms — incidents caused, time added to changes, features blocked — and an estimate of repayment cost. The list is the argument, and it is what 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; it is what keeps the register from growing, and it is nearly free because the engineer is already there.

The highest-interest allocation

The standing capacity share from SV-3 Roadmapping is spent on the register's highest-interest items, by impact against cost. Not the most annoying, not the oldest, not the one an engineer most wants to rewrite.

The rewrite challenge

A proposal to rewrite a working system is treated as a bet and evaluated as one: what the incremental alternative would 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; the ones that do are the ones worth funding.

The expiring-option review

When a departing expert, a fragile vendor or a single point of failure is discovered, the response starts that week: pairing, documentation, shadowing, redundancy. The option to act cheaply expires on a known date, and it outranks most roadmap items because of that date.

At team scope the object is the team's own debt and its repayment schedule, and the manager keeps it visible, prices it, and repays it incrementally. At organisational scope the object becomes systemic debt that no single team owns and the risk signals no single team can see; the manager reads them 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 at discovery. At executive scope debt is a strategic liability — the platform's runway, the business's exposure — decided at the executive table in business terms, with board commitments that are measurable remediation programmes rather than promises, and resilience verified rather than assumed. The pattern is in How Judgment Scales; 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
• States the honest trade-off with evidence when debt is slowing delivery and product wants no slowdown: the pace is borrowed from future quarters, here is the measured cost, here is the proposal. org
• Evaluates a large refactor with a hard-to-quantify payoff on proxy evidence, then stages and time-boxes it to prove 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; the option expires in weeks. org
• Treats a vendor outage that took down several teams as a systemic dependency discovery, 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, 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 instance by instance. 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 across many services as business risk, with explicit capacity and an honest roadmap impact, not squeezed into team slack. exec
• Commits to the board, after a major incident, a systemic remediation programme with measurable milestones and honest timelines — never "it won't happen again". exec
• Can answer, with evidence, whether the organisation survives its plausible bad days: single points of failure mapped, degradation graceful, recovery tested, key dependencies bounded. exec
• Keeps a short list of risks tracked personally: platform runway, security posture, reliability trends, 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 in the cushions. exec
• Failure mode — delegating reliability so completely that the trend arrives as the outage. exec

Expedience versus interest. Taking debt on knowingly is often right; the launch matters and the shortcut is understood. The tension is that the interest is paid by a future team, often a different one, and the judgment is in writing the loan down so that it is repaid rather than discovered.

Visibility versus alarm. A long debt register reads as a team in trouble; a short one hides the interest. The register is kept honest and priced, and the framing is control: here is what it costs, here is the schedule.

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

Repayment versus delivery. Every hour on debt is an hour not on features this quarter, and every hour not on debt is borrowed from a future quarter at interest. The stated capacity share is the resolution; the tension is in holding it when a launch is close.

Honesty versus reassurance at the board. After a serious incident the board wants to hear that it cannot recur, and the honest commitment is a measurable programme with timelines. Reassurance is instantly discrediting the next time; the programme is believable because it can be checked.

A team's manager is in sprint planning when a senior engineer proposes rewriting the order-processing service from scratch. The service is six years old, written in a framework the team no longer likes, and is 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 enthusiastic; the product partner is not in the room; the current roadmap assumes the whole team 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 engages with the actual question, which is what the debt costs and what the cheapest way to repay it is.

The manager starts with the register. The incident data supports the engineer's claim about the third of incidents, but 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 and unloved and rarely touched, and its incident rate is unremarkable. The debt is real, priced, and concentrated.

The manager puts the rewrite through the challenge. The incremental alternative — replacing the two modules in place, behind their existing interfaces, over six weeks with one engineer, and leaving the rest of the service alone — addresses the priced cost at a fraction of the price and lets reality vote after the first module. The rewrite, by contrast, replaces 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 so, plainly, with the numbers, and proposes the incremental path, funded from the team's standing debt share, starting with the reconciliation module.

The senior engineer is disappointed; they wanted the clean system. The manager gives them the lead on the two modules and says what would change the answer: if, after 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 hears that the team's debt share for the next six weeks is going to the thing causing a third of the incidents, in those terms.

What the manager does not do is fund a quarter-long bet on the strength of a capable engineer's enthusiasm, or 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 versus 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 — arguing debt to product and to the board in their terms.

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

   Taken 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 — incidents caused, time added to changes, features blocked — never in 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, evaluated as one. The incremental alternative is explored honestly first — where is the debt actually concentrated, what would replacing that in place 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

   Because the option to act cheaply — pairing, documentation, shadowing — expires on a known date. After it, 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, here is the measured cost, here is a proposal for an explicit capacity share targeted at the highest-interest debt. The decision gets made consciously, above you if necessary, not defaulted 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 — no system is incident-free — and the next incident makes everything else you say discredited.
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 through others but never fully delegate, 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.