Ward Cunningham coined “technical debt” as a metaphor. Somewhere along the way, we forgot the “metaphor” part.

Technical debt is not a metaphor. It is a real financial liability with measurable carrying costs, compounding interest, and — if left unchecked — the potential for organizational bankruptcy.

The problem is that engineering leaders talk about technical debt in engineering terms: “our test coverage is low,” “the monolith needs to be decomposed,” “we’re three major versions behind on React.” These statements mean nothing to the people who control the budget.

Here’s how to translate.

The Carrying Cost

Every piece of technical debt has a carrying cost — the ongoing expense of working around it. This is measurable.

Example: Your team spends an average of 8 hours per sprint dealing with flaky integration tests that should take 30 minutes to run but actually take 3 hours.

• 8 hours/sprint × 26 sprints/year = 208 hours/year
• 208 hours × $85/hour (loaded cost of a senior engineer) = $17,680/year
• Across 4 teams affected = $70,720/year

That’s not a metaphor. That’s a line item. A line item that compounds every time you hire another engineer who now also has to deal with the problem.

The Classification System

Not all technical debt is created equal. Use this classification to prioritize:

Reckless Debt

“We know this is wrong, but we’re shipping anyway.”

This is the debt incurred under deadline pressure with full awareness of the consequences. It has the highest interest rate because it typically involves security shortcuts, missing error handling, or architectural violations that will cause incidents.

Financial model: High carrying cost, high incident risk, short time-to-crisis.

Prudent Debt

“We’ll do it this way now and refactor when we learn more.”

This is strategic debt — consciously accepted to achieve a business objective with a plan to address it. It has a moderate interest rate and a predictable repayment schedule.

Financial model: Moderate carrying cost, low incident risk, known repayment plan.

Accidental Debt

“We didn’t know a better way existed.”

This is the debt that accumulates through lack of knowledge, outdated practices, or evolving industry standards. The interest rate is low initially but increases as the gap between your codebase and modern practices widens.

Financial model: Low initial cost, exponentially increasing carrying cost, contributes to talent retention risk (good engineers don’t want to work on outdated stacks).

Environmental Debt

“The world changed around us.”

Framework deprecations, library end-of-life, compliance requirement changes. This debt is not your fault, but it’s still your problem. The interest rate spikes when the dependency becomes a security liability.

Financial model: Zero cost until triggering event, then extreme cost under time pressure.

The Board Presentation

When presenting technical debt to the board, use this structure:

1. The Debt Register

A simple table that any executive can understand:

Debt Item	Annual Carrying Cost	Risk Level	Estimated Fix Cost	ROI
Flaky test suite	$71K	Medium	$120K	17 months
Legacy auth system	$45K + incident risk	Critical	$200K	12 months
Manual deployments	$156K	High	$80K	7 months
Outdated framework	$30K + talent risk	Medium	$300K	36 months

2. The Interest Rate

Show how the carrying cost compounds. If you’re growing your engineering team by 30% per year, the $71K test suite problem becomes $92K next year and $120K the year after, because more engineers are affected.

3. The Payoff Plan

Propose a structured payoff schedule, just like a financial debt repayment plan:

• 20% of sprint capacity allocated to debt reduction (non-negotiable)
• Quarterly debt review to reassess priorities
• Leading indicators to track: deployment frequency, incident rate, engineer satisfaction

The Uncomfortable Conversation

Here’s what you need to say to your CEO, and what it actually means:

“We need to invest in reducing technical debt.”

Translation: “We’ve been trading long-term sustainability for short-term velocity, and the bill is coming due. If we don’t invest now, our feature velocity will continue to decrease, our best engineers will leave for companies with better codebases, and our incident rate will increase.”

That’s not an engineering argument. That’s a business argument. And it’s the only kind that works.

---

The Garnet Grid perspective: We help CTOs quantify technical debt in financial terms that resonate with boards and CFOs. Because “we need to refactor” isn’t a business case — but “$156K annually in waste” is. Start with an architecture audit →