Tech Debt Payback Plan

00 The Credit Card You Never See the Statement For

Most tech debt is deferred payment, made under time pressure, with a silent promise to pay it back, not recklessness. The problem? Nobody ever opens the statement.

TECH •••• DEBT ••••

Cardholder

YOUR ENGINEERING ORG

Outstanding Balance

GROWING

Min. Payment Status

OVERDUE

TECH
VISA

The core analogy: Tech debt is a credit card that charges compound interest in the currency of velocity loss, risk accumulation, and developer frustration. Every sprint you skip the minimum payment, the balance grows. Keep missing it and you'll eventually only be able to afford interest payments, not features.

Financial Concept		Tech Debt Equivalent
Credit card balance	=	Accumulated shortcuts, hacks, missing tests
Interest rate	=	Compounding drag on every future change
Minimum payment	=	% of each sprint allocated to debt items
Debt consolidation	=	Refactor sprint / architectural overhaul
Balance transfer	=	Moving debt to a lower-cost structure: a dedicated sprint to pay off a single high-interest item and prevent new accumulation
Credit limit	=	Team's cognitive capacity / change failure rate ceiling
Credit score	=	Engineering Health Score (velocity, quality, risk)
Debt-free living	=	Continuous improvement as standard practice

01 Types of Debt (Know What's on Your Statement)

Not all debt is equal. Some carries punishing interest. Some was deliberate. Understanding the type shapes the payback strategy.

Critical / Payday Loan

Architecture Debt

Core structural decisions that now bottleneck everything. Monolith that should be modular, data model that fights your domain, coupling that makes changes spread like wildfire.

Interest rate: Extremely high. Every new feature pays a tax. Compounds silently until a crisis forces the hand.

Critical / Payday Loan

Security & Compliance Debt

Known vulnerabilities, unpatched dependencies, missing audit trails, incomplete GDPR/MDR/ISO controls. This isn't just risk, it's a liability with a due date you don't control.

Interest rate: Variable and catastrophic. Low until it isn't. Regulatory fines and breach costs are the balloon payment.

High / Store Card

Test Coverage Debt

Untested paths, manual regression that should be automated, brittle tests that pass for the wrong reasons. The codebase becomes a minefield where nobody's confident to refactor.

Interest rate: High. Slows every release cycle and inflates QA overhead linearly with codebase size.

High / Store Card

Operational Debt

Missing observability, manual deployments, absent runbooks, inconsistent environments. You can't see what's broken and can't fix it fast when it is.

Interest rate: High. Incident MTTR balloons. On-call becomes a tax on your best engineers.

Medium / Overdraft

Code Quality Debt

Duplicated logic, overly complex functions, poor naming, inconsistent patterns. Individually tolerable, collectively they make every PR a history lesson.

Interest rate: Medium. Compounds via onboarding friction and cognitive load per change.

Medium / Overdraft

Dependency Debt

Outdated libraries, end-of-life frameworks, forked dependencies with no upstream. You're one CVE away from an emergency upgrade on a framework you haven't touched in three years.

Interest rate: Medium-high and volatile. Often invisible until it becomes blocking.

Low / Student Loan

Documentation Debt

Missing ADRs, stale READMEs, onboarding gaps, decisions that lived in someone's head and left with them. Slows growth and concentrates knowledge risk.

Interest rate: Low individually, compounding at team scale. Worst during hiring spikes and org changes.

Low / Student Loan

Process & Tooling Debt

Manual steps that should be scripted, inconsistent branching strategies, CI pipelines nobody understands anymore, tooling that works for no team in particular.

Interest rate: Low-medium. Drags on developer experience and slows cycle time gradually.

Critical / Emerging Risk

⚡ AI Era

Codebase Cognitive Debt

The gap between how fast your team is shipping code and how well they actually understand it. Agentic AI tools let teams generate, refactor, and merge code at a pace that human comprehension can't keep up with. The codebase grows. The team's mental model of it doesn't.

Nobody wrote the code badly. Nobody cut corners. But if nobody on the team can reason confidently about how a system behaves, debug it under pressure, or safely extend it, the outcome is the same as if they had.

Interest rate: High and accelerating. Velocity looks healthy on the dashboard while comprehension silently degrades. The bill arrives at the worst possible moment, during an incident, a security review, or an onboarding that reveals nobody actually knows how the thing works.

Warning signals

Engineers accept AI-generated PRs they couldn't have written themselves and wouldn't confidently explain in a review
Debugging takes longer than expected because nobody has a reliable mental model of the affected code
Onboarding new engineers feels impossible: the codebase grew faster than any documentation or shared understanding of it
Tests pass but the team isn't sure why, and isn't confident that the tests are actually covering the right things
"I'll ask the AI" becomes the default for understanding existing code, not just writing new code

Payback strategies

Set a comprehension standard for PRs: can the author explain this change without AI assistance?
Run regular "archaeology sessions": dedicate time to understanding code the team shipped but didn't fully absorb
Write ADRs after AI-assisted architectural changes, not just human ones
Treat AI-generated code with the same (or higher) review rigour as human code: the reviewer owns it once it merges

02 The Debt Ledger (Open the Statement)

You can't pay down what you haven't catalogued. The ledger is your balance sheet. Run a debt discovery session every quarter, minimum.

Rule: If it's not written down, it doesn't exist as a managed liability. It exists as an invisible tax.

Debt Item	Type	Interest Rate	Est. Balance (days)	Owner	Priority	Status
Auth service tightly coupled to monolith	Architecture	Very High	45d	Platform	P1	In Progress
Payment flow has 0% unit test coverage	Test Coverage	High	10d	Payments	P1	Not Started
Node 14 EOL in 3 services	Dependencies	High	8d	Backend	P1	Scheduled
No centralised observability for batch jobs	Operational	Medium-High	12d	SRE	P2	Not Started
User service has 4 duplicated data access patterns	Code Quality	Medium	5d	Core	P2	In Progress
Onboarding guide last updated 18 months ago	Docs	Low	3d	EM	P3	Not Started

Template columns: Debt Item, Type, Interest Rate (High/Med/Low), Estimated Effort (days), Owner, Priority (P1–P3), Status. Consider also tracking: Date Logged and Target Resolution Sprint in your team's Jira or equivalent.

Debt Scoring Formula

Debt Score = 2 ⋅ (Impact × Likelihood) - Effort

A weighted, risk‑first score that pushes the highest‑impact, highest‑likelihood items to the top... Sound familiar? It's the engineering equivalent of an avalanche payoff on a credit card.

03 Compound Interest (The Cost of Doing Nothing)

Tech debt interest is paid invisibly, every sprint, in reduced velocity, slower onboarding, higher change failure rates, and engineer frustration.

Velocity Tax

Slower Feature Delivery

Each new feature takes longer because engineers have to navigate around (or fix) debt before making their change. The workaround becomes the norm. The norm becomes 2x the effort.

Incident Tax

Higher Change Failure Rate

Untested, poorly understood code breaks more often when touched. Your DORA change failure rate rises. Each incident costs time and trust. The interest is paid in post-mortems and late nights.

People Tax

Engineer Attrition

Nobody stays to maintain a codebase they're ashamed of. Debt-heavy systems drive away good engineers and repel strong candidates. Research consistently places software engineer replacement cost at 100–200% of annual salary, with specialist roles higher. That's a real balance.

Opportunity Tax

Strategic Paralysis

When the team is 60% reactive, you can't move on opportunities. Debt steals your ability to respond to market changes. This is the compound interest that compounds the longest.

04 Minimum Payments vs. Strategic Paydown

Define your payment commitment before the sprint starts. Just like setting up a direct debit, you need to make this automatic, not a decision you revisit every two weeks.

Minimum Payment

10%

One sprint slot, every sprint, no matter what. Prevents the debt balance from growing. Interest payments only. You're not moving the needle, but you're not falling further behind.

Standard Paydown

20%

Two sprint slots, consistently applied. For most teams, can actively reduce balance over 6–12 months with visible improvement in velocity metrics. This is your "sensible budget" position.

Accelerated Paydown

30%+

Post-incident, post-audit, or when a major initiative demands a clean foundation. May require a dedicated "debt sprint" with stakeholder sign-off. Sustainable for 1-2 cycles, not indefinitely.

Debt sprint (balance transfer): Sometimes the right move is a dedicated consolidation sprint, where the whole team targets a single high-interest debt item. Like a balance transfer, it only works if you don't immediately rack up new debt the next sprint.

Anti-pattern to avoid: "We'll pay it back next quarter." Without a named owner, a named sprint, and a named ticket, this is the same as saying "I'll definitely pay off this credit card when I get the bonus." You won't. You'll spend the bonus on features.

05 The Runbook (Your Payback Playbook)

Eight repeatable steps. Run this on a quarterly cadence, with lightweight check-ins every sprint. Think of it as your monthly statement review.

1

Discovery

Open the Statement

You cannot pay down debt you haven't acknowledged. Run a structured debt discovery session with the whole engineering team. No blame, no excuses, just inventory.

Run a 60-minute team session: "What slows us down that isn't a feature request?"
Include EMs, senior engineers, QA leads, and SREs. Each has a different debt lens.
Use sticky notes or a structured form: item, type, rough effort, impact.
Don't filter at this stage. Capture everything. Prioritise later.
Output: Raw debt inventory in a shared doc or Jira epic.

2

Classification

Sort by Interest Rate

Assign each item a type (from Section 01) and a rough interest rate: Critical, High, Medium, Low. This determines payback urgency, same as sorting credit cards by APR.

Map each item against the 8 debt types in this framework.
Use the scoring formula: 2 ⋅ (Impact × Likelihood) - Effort.
Flag anything that touches security, compliance, or core revenue paths as Critical.
Mark items that are "invisible to product" so they don't get deprioritised unfairly.
Output: Debt Ledger with priority scoring applied.

3

Ownership

Assign a Debt Owner

Every debt item needs a named owner, not a team. Shared ownership is no ownership. The owner doesn't have to fix it alone, but they do have to make sure it moves.

Assign an owner and owning team for every P1 and P2 item.
P3 items can be owned by team leads collectively.
Owner is accountable for: keeping the ticket updated, raising blockers, and estimating effort.
Review ownership quarterly. Ownership should rotate where appropriate.
Output: Ledger updated with Owner column populated.

4

Budgeting

Set Your Sprint Allocation

Agree the minimum payment percentage with your EM and Product counterparts before the next sprint planning. This isn't negotiable per sprint, it's a standing commitment.

Default to 20% of sprint capacity as the standard paydown allocation.
Present the case to Product using the financial analogy. "We're paying 20% on a debt that's costing us X days per sprint in slowdown."
Document the agreed percentage in the team working agreement or sprint charter.
Treat capacity like a direct debit: take debt slots first, then plan features around the remainder.
Output: Team working agreement updated. Sprint template reflects allocation.

5

Planning

Sequence the Paydown

Use a debt payback sequence. Like the debt avalanche method in personal finance: hit the highest interest rate items first, then roll the freed-up capacity into the next.

Pull from your P1 items first. If none fit within sprint capacity, break them into slices.
Never push the same P1 item more than two consecutive sprints without escalating.
For large architectural debt, use the "balance transfer" approach: plan a dedicated debt sprint with a clear scope and success criteria.
Pair debt items with related feature work where possible to increase the perceived ROI for stakeholders.
Output: Sprint backlog includes debt items tagged with [DEBT] and linked to the ledger.

6

Transparency

Report on the Balance

Make the debt visible to stakeholders without drowning them in detail. One number: your Engineering Health Score. One chart: debt balance over time. Monthly.

Create a lightweight debt dashboard: total items, critical items, items closed this month.
Track your Engineering Health Score (see Section 06) and share trends, not just snapshots.
Present to leadership quarterly. Frame it as: "Our debt balance, what it's costing us, and our paydown trajectory."
Never use debt reporting to shame teams. Use it to justify capacity and surface systemic patterns.
Output: Monthly debt summary in engineering all-hands or equivalent.

7

Prevention

Don't Buy More Than You Can Afford

New debt is fine, as long as it's deliberate and tracked. Reckless debt, accrued without awareness, is the problem. Set a definition of "acceptable short-term debt" for your team.

Define what constitutes "acceptable debt" in your team: time-boxed shortcuts with a logged payback ticket within 2 sprints.
Add a "debt check" to your PR template: "Does this introduce debt? If yes, has a ticket been raised?"
Make debt creation a conscious, logged act, not an accidental one.
Review new debt items weekly in standup or retro. Keep the ledger live, not just a quarterly exercise.
Output: PR template updated. Team norms written down in the working agreement.

8

Review

Quarterly Statement Review

Once a quarter, run a full ledger review. Items get repriced (impact may have changed), reordered, and sometimes written off. Just like reviewing your finances.

Review all open items. Archive anything that's no longer relevant, such as a system you decommissioned.
Reprice items where the impact or effort has changed.
Celebrate closed items. Paydown is progress and worth acknowledging.
Check if the team's capacity allocation is working. Adjust if debt isn't moving.
Re-run the discovery session to catch new debt from the last quarter.
Output: Updated ledger, adjusted sprint allocation if needed, and a short team retrospective on debt trends.

06 The Engineering Health Score (Your Credit Score)

A single number that captures the overall financial health of your engineering system. Not a report card, a navigation instrument.

Engineering Health Score

Composite of: Deployment Frequency, Change Failure Rate, MTTR, Coverage Trend, Dependency Risk, Open Debt Balance.

CRITICAL POOR FAIR GOOD EXCELLENT

Critical

Reactive mode. Debt is the dominant force. Immediate intervention required.

Poor

Growing balance, slipping velocity. 30% allocation minimum. Leadership visibility needed.

Fair

Debt exists but is acknowledged. Paydown has started. Needs consistent cadence to improve.

Good

Stable. Debt managed at 20% allocation. Balance slowly reducing. Keep cadence.

Excellent

Debt as an engineering practice. Continuous improvement is the default mode.

Simplified Health Score Inputs

Deployment Freq + CFR + MTTR + Coverage Delta + Critical Debt Count

Normalise each input to a common 0–10 scale before summing: raw values have incompatible units. Weight each signal to your context. Track trend over 3 rolling quarters, not point-in-time. A rising score matters more than the absolute number.

07 Quick Wins to Start This Sprint

Before you build the full framework, get momentum. These take hours to days, not sprints. Like making a small extra credit card payment, it builds the habit and reduces the balance immediately.

Run a 60-minute debt discovery session

Just ask the team: "What slows us down that isn't a feature?" You'll have 20 items by the end of the hour.

Add a [DEBT] label to existing Jira tickets

Instant visibility. You can filter, track, and report on it from tomorrow morning without any new tooling.

Reserve one sprint slot as a standing rule

Even 10% is enough to stop the balance growing. Put it in the team working agreement. Don't ask per sprint.

Upgrade your top 3 EOL dependencies

High interest, usually low effort. A few days of work removes a compounding security and stability risk.

Write a test for the most-changed file last sprint

The file you changed most is the one most likely to break next. Cover it first. Coverage where it counts.

Add a debt check question to your PR template

"Does this introduce debt? If yes, has a ticket been logged?" Takes 5 minutes to add. Changes the culture long-term.

Pull last quarter's change failure rate

Your CFR is a proxy for debt interest. If you don't know it, find out now. It's the number that turns heads in leadership.

Present the credit card analogy to your Product Manager

"We're paying 20% interest on a debt that's slowing every sprint. We need a minimum payment." It lands differently when the metaphor is financial.

∞ The Golden Rule

Pay more than the minimum. Every sprint.

The teams who ship fast and stay reliable aren't the ones who never take on debt. They're the ones who treat debt as a managed liability, not a fact of life. They know what they owe, who owns it, and when it's getting paid. That discipline is the difference between a team that accelerates over time and one that gradually grinds to a halt, wondering why everything takes so long.