Ward Cunningham coined the term “technical debt” in his 1992 OOPSLA experience report to describe the gap between what code embodies and what the developers have since learned. His metaphor was deliberately narrow. What follows is an intentional extension of it, because the software industry adopted the word “debt” three decades ago and never built the accounting discipline around it. We say “technical debt” constantly, yet we rarely apply the frameworks that actual debt management demands: classification by instrument type, risk-weighting, amortization schedules, default thresholds. In the payments world, balance sheet discipline is existential. Engineering organizations operating at the same scale deserve the same seriousness, and the vocabulary is already sitting right there, waiting to be used properly.
Every CFO I’ve worked alongside can rattle off their organization’s debt instruments, their terms, their risk ratings, their servicing schedules. Walk over to the engineering side of the same building, and technical debt lives in a Jira epic labelled “tech debt” with no due date, no carrying cost estimate, and no default risk analysis. If the CFO reported all financial debt as a single undifferentiated line item, the board would lose confidence in the CFO’s grasp of the portfolio. Engineering leaders present technical debt in exactly those terms, and the board nods along because they lack a better framework to push back with.
The Financial Instruments of Technical Debt
Financial debt is not a single category. A revolving credit line, a thirty-year mortgage, and a junk bond all carry the label “debt,” yet they have wildly different risk profiles, servicing costs, and consequences for default. Technical debt deserves the same granularity, because treating all of it as one undifferentiated lump is precisely how engineering organizations end up paralyzed by it.
Revolving credit is the quick hack you merge on Thursday because a partner integration deadline is Monday. You know you’ll clean it up next sprint, the carrying cost is low, and the team can service it without breaking stride. Every engineering team carries some of this, and in moderation it’s healthy; a team with zero revolving technical debt is probably shipping too slowly, the same way a business that never uses a credit line is probably leaving growth on the table.
Term loans are the larger architectural compromises you make with a clear paydown plan. You chose a monolith because the team was small, and the migration to services is a two-quarter project with a known scope. The principal is well-understood, the interest payments (slower feature velocity, tighter coupling) are predictable, and the amortization schedule lives on the roadmap. This is responsible leverage. The danger is when the repayment date keeps slipping to the right, because a term loan that never gets repaid is a mortgage you haven’t acknowledged.
Mortgage debt is the foundational technology choice that will take years to unwind: the programming language, the core data model, the cloud provider. You’re paying interest on it every month in the form of hiring constraints, ecosystem limitations, and integration overhead, albeit the payments are manageable and the asset underneath appreciates if you chose well. Mortgages are the debt most organizations carry deliberately, and correctly so; the mistake is pretending they don’t have a carrying cost.
Junk bonds are the shortcuts taken under duress with no paydown plan, accumulating interest faster than the team can service it. A hand-rolled authentication layer built during a hackathon that somehow made it to production. A data pipeline held together by cron jobs and optimism. The defining characteristic of junk-bond tech debt is that the team has stopped even estimating how long it would take to fix, because the number is too demoralizing. In financial markets, junk bonds pay high yields precisely because of their default risk; in engineering, the yield is ship speed in the short term, and the default event is the quarter where everything grinds to a halt because you can no longer safely change the system.
A team with zero revolving technical debt is probably shipping too slowly, the same way a business that never uses a credit line is probably leaving growth on the table.
Principal, Interest, and Default Risk
Once you have the instrument taxonomy, the financial accounting model extends naturally. Every piece of technical debt has a principal: the cost of the original shortcut, measured in engineering-weeks to remediate. It also carries interest: the ongoing tax on productivity that you pay when engineers work near the affected code. One important disanalogy with financial debt: technical debt interest is activity-triggered rather than calendar-triggered. A terrible module you never touch costs you nothing in carrying costs, whilst one that sits at a critical intersection of your codebase charges interest on every feature that passes through it. The framework is still worth using precisely because it forces you to ask which debt sits on hot paths and which sits inert, a distinction that changes your paydown priority entirely.
A poorly designed API surface costs far more than the eventual rewrite. It costs you every week in the form of longer onboarding for new engineers, extra integration work for partner teams, and a higher defect rate in the code that touches it. The compounding paths are often invisible until you trace them: a fragile integration test suite slows down CI, which erodes developer confidence in the test signal, which leads to more manual verification, which lengthens release cycles, which increases batch size, which makes deployments riskier. The original debt was a poorly designed test fixture; the compounding interest touches the entire delivery pipeline.
Default risk is where the financial metaphor becomes most useful for board-level conversations. A company defaults on debt when it can no longer make interest payments. An engineering organization defaults on technical debt when the accumulated shortcuts make it impossible to ship reliably: every change risks a cascading failure, and the team spends more time working around existing debt than building new capabilities.
I’ve seen this at organizations where the debt load crossed a threshold and suddenly a system that had been “fine” for years started producing incidents weekly. The debt itself hadn’t changed; the interest had compounded past the team’s capacity to service it. The warning signs are measurable, if you choose to measure them: the ratio of bug fixes to feature work over time, how long it takes a new engineer to ship their first meaningful change, and how often incidents trace back to known unresolved debt. These are your debt service metrics, and they belong in your engineering review alongside velocity and uptime.
The Amortization Schedule
Finance teams don’t tell the board “we’ll pay off our debt when we get around to it.” They present amortization schedules: structured, time-bound plans that show exactly how much principal gets retired each period and what the remaining balance looks like over time. Engineering organizations should do the same.
An amortization schedule for technical debt means committing a specific, predictable percentage of engineering capacity to debt paydown every quarter. In the mid-stage organizations I’ve worked in, 15-20% has been a sustainable rate, enough to make real progress without starving product delivery. The critical discipline is protecting that allocation from the inevitable pressure to redirect it toward feature work when deadlines loom, because that pressure is exactly how term loans become mortgages.
The schedule should be instrument-specific. Revolving credit gets paid down within the sprint where it was incurred, or at least within the same quarter. Term loans need explicit milestones on the roadmap with engineering owners and completion criteria, whilst mortgages require multi-quarter restructuring plans reviewed each quarter. Junk bonds are the exception: they get immediate triage, either converting them to a properly structured instrument with a paydown plan or flagging them as default risks that require executive attention.
A term loan that never gets repaid is a mortgage you haven’t acknowledged, and a mortgage you haven’t acknowledged is a junk bond waiting to default.
Presenting the Balance Sheet to a Finance-Fluent Board
The disconnect between engineering and the boardroom comes down to language. Leadership can grasp technical problems perfectly well, but engineering keeps presenting those problems in engineering language rather than business language. I’ve sat in rooms where an engineering leader asked for “20% of capacity for tech debt reduction” and received blank stares followed by polite rejection. The same underlying request, reframed as a balance sheet with specific instruments, risk ratings, and an amortization schedule, gets genuine engagement, because the audience already has decades of experience evaluating exactly those concepts.
The format I’ve landed on:
Start with a debt inventory: every significant piece of technical debt cataloged as a named instrument with a type (revolving, term, mortgage, junk), an estimated principal in engineering-weeks, and a current interest rate expressed as a percentage of team capacity dragged down by workarounds.
From there, compute a risk-weighted exposure by weighting each item according to blast radius and likelihood of default. A well-understood term loan with a paydown plan looks very different from a junk bond sitting in a critical payment processing path, and the board needs to see that distinction. This maps directly to how banks compute risk-weighted assets, and any finance executive will recognize the structure.
The amortization schedule turns the inventory into a commitment. For each item you propose to remediate, present a paydown timeline with milestones: “We will migrate the authentication layer over two quarters, reducing incident rate in that surface by an estimated percent and freeing approximately three engineering-weeks per quarter currently spent on workarounds.” Vague promises to “address tech debt” give a board nothing to evaluate; a timeline with milestones gives them something to hold you accountable against.
Finally, establish a debt ceiling, a maximum acceptable debt load beyond which you refuse to take on more, reviewed quarterly. This is the most powerful element of the framework, because it forces the trade-off conversation before it becomes a crisis and gives engineering leaders cover to push back when the business asks for another shortcut: “We’re at our debt ceiling. Taking this on means explicitly accepting the default risk on item X.”
Debt Is Leverage, Not Sin
The goal is never zero debt but rather intentional leverage: knowing exactly what you owe, what it costs you each quarter, and when you plan to pay it down. Debt, wielded deliberately, is how organizations move faster than their current capacity would otherwise allow. The organizations that get into trouble are the ones carrying debt they haven’t inventoried, can’t quantify, and have no plan to address.
Every shortcut your team takes is a financial instrument. Start treating it like one. Classify it, rate it, schedule the paydown, and present the portfolio in language the rest of the leadership team already speaks fluently. The discipline does more than improve board communication; it forces the rigor that makes the debt manageable in the first place, something finance figured out centuries ago. The vocabulary is already sitting there, waiting for engineering to use it properly.