Technical Debt: How to Score It, When to Pay It

The Loan Nobody Signed For

Technical debt is the only loan a company can take out without the CFO's signature. Every shortcut shipped under deadline pressure, every system nobody dared touch after its author left, every "temporary" integration now in its sixth year — each one added principal. And the business services that loan every quarter, whether or not anyone can see the payments.

The payments are real but scattered, which is why they never show up as a line item. They show up as the feature that took four months instead of four weeks. The estimate padded by half "because you never know what you'll find in there." The release that broke something that used to work. The engineer who can't take vacation because a production system lives in their head. None of these say "technical debt" on the invoice. All of them are interest.

The reason debt keeps winning budget arguments is that only one side of the ledger gets quantified. The cost of fixing it gets an estimate; the cost of keeping it stays a feeling. This article is about fixing that asymmetry — scoring debt in business terms, deciding what to pay first, and knowing which debt you should deliberately keep.

Score the Carry Cost, Not the Code

Engineering teams instinctively score debt by code quality: complexity metrics, test coverage, static analysis warnings. Those numbers are true and useless in a budget meeting, because nobody funds a refactor to improve a maintainability index. Leadership funds outcomes. So score the debt the way a CFO scores a loan — by what it costs to carry.

Four carrying costs cover almost everything:

• Delivery drag. The gap between what a change should cost and what it costs in your indebted systems. If a competitor ships a comparable feature in six weeks and you need six months, the difference is mostly debt service — and it compounds, because slow delivery invites more shortcuts.
• Key-person risk. Every system that depends on one person is an outage with a resignation letter attached. Price it as what it would cost — in time, money, and lost commitments — to operate that system for ninety days without them. Then remember that departures rarely give ninety days' notice.
• Deployment fear. When releases need a specific person watching, a weekend window, and a prayer, teams release less often. Each release gets bigger, riskier, and slower to diagnose — fear creates the failures it fears. The carrying cost is every improvement your teams didn't ship because shipping hurt.
• Changeability loss. The strategic option you can't exercise: the vendor you can't replace because the integration is welded in, the acquisition you can't absorb, the AI initiative that dies in discovery because the data lives in a system nobody can safely extend. This is the most expensive cost and the least visible, because it appears as strategies never attempted.

Score your top systems against those four dimensions and you have something no complexity metric provides: a debt register the executive team can read, with each item priced in delay, risk, and forgone options rather than in code smells.

When to Pay — the Sequencing Rule

You can't pay it all, and you shouldn't try. Big-bang rewrites fail so often they're an actuarial category of their own — eighteen months of parallel builds, a migration everyone dreads, and a new system that faithfully recreates the old system's assumptions. Paydown works when it's sequenced, and the sequence follows one rule: pay the debt on the road you're about to drive.

Debt in a system you'll replace next year is debt you should mostly ignore. Debt in the system that sits under this year's product strategy, your next acquisition, or your AI roadmap is debt with a deadline. Rank your register by where the business is going, then apply three filters:

• Pay immediately: debt that blocks the roadmap. If the strategy needs a system to change and the system can't change safely, that debt is a strategic blocker priced as an engineering ticket. It goes first, always.
• Pay on schedule: debt that compounds. Key-person risk, end-of-life platforms, and missing test coverage all get more expensive with time. These get the standing allocation — a protected 15–20% of engineering capacity every sprint. Consistency beats heroic cleanup quarters, which reliably get cancelled the moment a deadline appears.
• Don't pay: debt that's stable and off the road. The stable internal tool on an old framework, touched twice a year, understood by three people and due for retirement — leave it. Paying that debt back is buying a renovation for a house you're selling. Deliberate, documented non-payment is a legitimate portfolio decision; unexamined non-payment is just drift.

That last category is what separates debt management from debt anxiety. The goal was never zero debt — companies with zero technical debt ship too slowly to accumulate any. The goal is chosen debt: every item known, priced, and either scheduled or consciously carried.

The Conversation This Unlocks

Something changes when debt is scored this way. The engineering leader stops asking for "time to refactor" — a request that loses to every feature on every roadmap — and starts presenting a portfolio: here are our ten largest debt items, here's what each costs per quarter to carry, here's the paydown cost, and here's the sequence that protects the strategy. That's not a complaint. That's a capital allocation proposal, in the only language budget decisions actually speak.

And it cuts both ways, usefully. A CFO who sees the register can legitimately decide to carry some debt for another year — that's their call to make, and now it's made with numbers instead of by silence. What the register ends is the worst outcome: debt accumulating invisibly until it surfaces as a missed market window, a failed audit, or a resignation that turns into an incident.

If you don't know where your organization stands, start with a score. Our free Technical Debt Score measures the four carrying costs in twelve questions and places you in one of three bands — Critical, Mounting, or Manageable — with specific next steps for each.

John

Founder, Splendor Technologies

20+ years in AI, enterprise architecture, and application development. Helping organizations modernize technology and drive measurable business outcomes.