Technical Debt: Measuring It, Managing It, and Selling Remediation to Your CFO

Ward Cunningham coined "technical debt" in 1992 to describe the cost of additional rework caused by choosing an easy solution now instead of a better approach that would take longer. The metaphor was meant to communicate to non-technical stakeholders that software shortcut decisions accumulate interest — the short-term debt of "we'll fix this properly later" compounds into long-term cost.

The metaphor works in principle. It fails in CFO discussions because debt in financial terms is visible (it appears on the balance sheet), has a defined interest rate, and has clear consequences for not paying it. Technical debt is invisible on any balance sheet, has no defined interest rate, and compounds into a fog of accumulated symptoms — slower development, more bugs, harder-to-onboard engineers, occasional incidents — rather than a single visible consequence.

This guide covers how to make technical debt visible, how to manage it systematically, and how to present the case for remediation in language that lands with financial decision-makers.

What Technical Debt Actually Is

Technical debt is not a synonym for "things we wrote badly." It has two distinct types:

Deliberate debt: An intentional decision to take a shortcut, with awareness of the trade-off. "We're hard-coding this configuration rather than building a proper configuration management system, because we need to ship by Friday and we'll refactor it next sprint." Deliberate debt is acceptable if it is recorded, tracked, and actually addressed in the planned timeframe. It becomes problematic when the "we'll fix it later" never arrives.

Inadvertent debt: Code that was not a deliberate shortcut but turns out, over time, to be a design problem. An architecture decision that made sense at 10,000 users does not scale to 1,000,000. A monolithic codebase that made sense for a 3-person team does not support a 15-person team working in parallel. Inadvertent debt is the inevitable product of building software in an environment that changes — the requirements, the scale, the team, the technology ecosystem — over time.

Both types accumulate interest in the same way: they slow future development, increase defect rates, increase the difficulty and cost of onboarding new engineers, and create operational risk.

Measuring Technical Debt

To present technical debt to a CFO, you need to translate it into business-impact terms. The sequence:

Step 1: Identify the Debt

A technical debt audit identifies where the debt is. Categories to assess:

Code quality: Complex methods, high cyclomatic complexity, poor test coverage of critical paths
Architecture: Coupled components that should be separated, shared databases that create implicit dependencies, missing abstractions
Dependencies: Outdated library versions with known vulnerabilities or no longer receiving security patches; deprecated platform components
Documentation debt: Code that is undocumented to the point where changes require significant investigation time
Infrastructure debt: Manual deployment processes, missing monitoring, absent alerting

Tools: Static analysis (SonarQube, ESLint with complexity rules, CodeClimate) can automate part of the assessment. The rest requires engineering team knowledge.

Step 2: Estimate the Remediation Cost

For each significant debt item, estimate the engineering effort to remediate it. Be specific: "Refactoring the payment service to separate the charge calculation from the ledger posting: estimated 8 developer-days."

Also estimate the probability and cost of not remediating: "This coupling has caused 3 incidents in the past 12 months, each requiring 2 days of engineer investigation and fix time."

Step 3: Calculate the Interest Cost

The interest on technical debt is what it costs in engineer time and operational impact over a defined period (12 months) if not remediated:

Velocity impact: Estimate what percentage of developer capacity is absorbed by working around the debt item (extra time to understand the code, extra time to test carefully, extra time to handle the integration complexity). For a ₦300,000/month developer spending 20% of time navigating a poorly designed module: ₦60,000/month × 12 months = ₦720,000 annual interest cost.
Defect cost: Incidents caused by the debt item, including investigation time, fix time, and any business impact (downtime, customer impact, support cost).
Opportunity cost: Features not built because capacity was consumed by debt-related work.

Communicating Technical Debt to Non-Technical Decision-Makers

The CFO analogy that works best is maintenance deferral in physical infrastructure. A company that defers maintenance on its generator fleet for three years saves the annual maintenance cost — until the deferred maintenance produces a failure that costs five times the deferred maintenance in emergency repair. The CFO who approved the deferral understands this in retrospect; the objective is to build the quantitative case that makes the equivalence visible in advance.

The maintenance backlog model: Present technical debt as a maintenance backlog with quantified items. Each item has:

An estimated remediation cost (one-time investment)
An estimated annual cost if not remediated (interest: developer time lost, incident cost)
A risk multiplier (how likely is the worst case, and what does the worst case cost)

Aggregated across the meaningful debt items, this becomes a portfolio: total remediation investment required, total annual cost of not remediating per year, implied break-even point.

Example CFO presentation structure:

"Our current technical debt portfolio represents an estimated ₦4.2M in remediation effort. Carrying this debt costs us approximately ₦8.4M per year in absorbed engineering capacity and incident costs. At this rate, the debt is free to remediate within 6 months in terms of recovered engineering capacity alone, before counting the avoided incident risk. The top 3 items represent 60% of the cost and 40% of the remediation budget. Our proposal is to invest ₦1.7M to address those 3 items over the next quarter, recovering the investment within 5 months."

This is a capital allocation argument. It does not require the CFO to understand code complexity; it requires them to evaluate a return-on-investment claim that follows a standard financial decision structure.

Managing Technical Debt Systematically

The worst outcome is the periodic emergency remediation project: debt accumulates until it causes a crisis, a project is commissioned to fix it, and the cycle repeats. Systematic management prevents the emergency project by keeping debt serviceable.

Debt backlog: Maintain a technical debt register. Each item has a description, an estimated size, an estimated annual carrying cost, and a priority. The register is reviewed in every planning cycle.

The 20% rule: Reserve 20% of engineering capacity in each sprint for technical debt remediation. This is the most common systematic approach. It prevents debt accumulation from crowding out feature work by treating maintenance as a first-class budget item, not an afterthought. In practice, teams that implement this consistently find that the 20% investment reduces the drag on the other 80% enough that net feature output increases.

Definition of done for new work: No new feature should be completed without meeting a quality standard that prevents it from immediately introducing new debt. Code review requirements, test coverage requirements, documentation requirements. This controls the rate of debt accumulation.

Refactoring as part of feature work: When a developer is working on a feature that touches a debt-laden module, they refactor the module as part of the feature work. This is the Boy Scout principle: leave the code cleaner than you found it. It does not require dedicated refactoring projects for incremental improvement.

When Emergency Remediation Is Unavoidable

Some technical debt reaches a state where it cannot be managed incrementally — a core system component is so fragile that changes require weeks of investigation, the risk of incidents is high, and developer morale is degraded by working in an environment of accumulated complexity. In this state, a focused remediation project is warranted.

Structure it as a project with clear deliverables, duration, and success criteria — not as "let's clean things up." Define which specific debt items will be addressed, what the system will look like at the end, how you will measure success, and when regular feature development will resume. Without this structure, remediation projects expand indefinitely.

The emergency remediation project is the cost of having deferred systematic management. Done once, it resets the baseline. The objective after the project is to never need another one — by implementing the systematic management practices that prevent the re-accumulation.

Technical debt is not a technology problem. It is a management problem that technology makes visible. The companies that manage it well are not the ones with the cleanest code; they are the ones that maintain the discipline to treat maintenance investment as a non-negotiable budget line rather than a discretionary one.

Hidden Costs of Maintaining Legacy Systems — The true cost of keeping old software running
The CFO's Guide to Security ROI — Speaking the CFO's language about technology investment
Real Software Project Scope: Why Estimates Change — Understanding project estimation realities