When an engineering team asks the board for time to pay down technical debt, the board hears a request to spend money fixing something that already works. That request usually fails, and it usually deserves to, because it is the wrong request in the wrong language. "The code is messy and we would like to clean it up" is not a business case. It is an aesthetic complaint with a budget attached.
The metaphor everyone reaches for — debt — is the right one. We just stop using it exactly where it starts to pay off. A loan has two numbers: the principal you borrowed and the interest you pay to carry it. Engineering teams estimate the principal obsessively — the rewrite is six weeks, the migration is a quarter — and almost never quantify the interest. So they walk into the room asking to retire a balance, when the number that would actually move a board is the one describing what that balance costs them every single sprint they carry it.
I report to boards. The requests that get funded are the ones expressed as a carrying cost the business is already paying, not a future project the business could choose to skip. Technical debt is fundable on exactly those terms. You just have to report the interest.
Principal is what you borrowed. Interest is what you pay to carry it.
Ward Cunningham, who coined the debt metaphor in 1992, was careful about which half he meant. His point was never the principal. "Every minute spent on not-quite-right code," he wrote, "counts as interest on that debt." The debt itself — the shortcut, the wrong abstraction, the schema that made sense two products ago — is survivable. What compounds is the tax you pay every time you touch the code around it.
That distinction is the whole game, and most teams get it backwards. The principal is the visible number: the size of the mess, the line count of the module everyone hates, the multi-week estimate to rip it out. It is legible, it is dramatic, and it is almost never the thing that should be scheduled first. The interest is the invisible number: the extra day every feature in that area takes, the coordination call that has to happen because two systems that should be one are two, the incident that traces back to a workaround, the week a new hire loses learning why the thing is shaped the way it is. Nobody writes those down, so they never appear in a budget, so the board never sees them. They are paid anyway — out of velocity, out of morale, out of the reliability the board does care about. They are simply paid off the books.
The uncomfortable implication: the biggest mess is often not the most expensive debt. A hideous module that no one has touched in three years is a zero-interest loan. It is ugly and it is free. Paying it down is spending capital to retire a balance that was not costing you anything. The expensive debt is the merely-annoying code sitting in the path every team crosses ten times a sprint. Low principal, ruinous interest. If you prioritize by the size of the mess, you will spend your refactoring budget on the wrong loans.
The interest is a velocity tax, and it is already measurable
The reason "clean up the code" fails as a business case is that it points at the principal. The reason "report the interest" works is that the interest is not a feeling. It leaves fingerprints in systems you already run.
The DORA research program — the four-keys work behind the annual State of DevOps reports — gave the industry a vocabulary for this without ever using the word debt. Change lead time, deployment frequency, change failure rate, and time to restore are not just delivery-health metrics. Sliced by area of the codebase, they are an interest-rate table. The subsystem where lead time is triple the median, where a large share of changes fail, where restores take longer than anywhere else — that is not a low-performing team. That is a high-interest loan, and the team is making the minimum payment every sprint. When you can point at a heat map and say "changes in the ledger service cost us three times what the same change costs anywhere else, and here is the trend," you have converted an aesthetic complaint into a carrying cost with a number on it.
You do not need a maturity model to start. Onboarding time to first meaningful change, the count of changes that require touching more than one system that should be one, the share of incidents whose root cause is a known workaround, the ratio of a subsystem's change-failure rate to the fleet median — any of these is a serviceable interest meter. The goal is not precision to the decimal. The goal is a number that trends, so that "we are carrying more debt than last quarter" stops being a vibe and starts being a line that moves.
Report a debt-service ratio, not a debt inventory
Here is where most engineering leaders lose the room. They bring the board an inventory — a catalog of the twelve worst modules, ranked by how much they offend. A board cannot do anything with an inventory. It is status, not a decision, and I have argued before that status content belongs in the appendix, not the front of the pack.
Consumer lenders do not evaluate a household by listing its ugliest debts. They compute a debt-service ratio: the share of income that goes to servicing debt rather than to everything else. Corporate finance does the same thing from the other end with a debt-service coverage ratio. The number is powerful because it is bounded, it trends, and it maps directly to a decision — above a threshold you are over-levered, and you stop taking on new obligations until you bring it down.
Engineering has the same ratio available and almost never reports it: the share of engineering capacity spent servicing debt rather than building new value. Rework, working around known-bad systems, the coordination tax, the incident load that traces to shortcuts — divided by total capacity. Capacity accounting is fuzzier than cash, so I would rather report an honest estimate that trends than a false precision that does not. But a board can hold a single sentence — for illustration, that a third of engineering capacity currently services debt, up from a fifth a year ago, with the real numbers yours to measure — in a way it can never hold a list of module names. That one ratio reframes the ask. You are no longer asking to spend money on cleanup. You are showing the board a carrying cost that is crowding out the roadmap they already approved, and asking which loans to restructure to get it back.
Price each loan by its interest rate, not its balance
Once debt is a portfolio of loans with interest rates, it gets managed like one. The interest rate on a piece of debt is roughly its touch frequency times its cost per touch: how often does work cross this code, and how much does each crossing cost. That product, not the size of the balance, is what should drive the schedule.
Martin Fowler's widely cited tech-debt quadrant sorts debt by how it was taken on — deliberate or inadvertent, prudent or reckless. That is useful for the postmortem: reckless-inadvertent debt is a process problem you should fix upstream so you stop manufacturing more of it. But it says nothing about what to do with the debt you already carry. The interest-rate view does. Sort the ledger by touch-frequency-times-cost and the schedule writes itself — the expensive, frequently-crossed loans go first, the cheap-but-annoying ones wait, and the genuinely dormant balances get left exactly where they are.
This is also where the accounting analogy earns a caution. Much internal software development gets capitalized — under ASC 350-40 in US GAAP it lands on the balance sheet as an asset and amortizes over years. I am not your controller, and this is a working engineer's read rather than accounting advice, but the shape matters: capitalization records what you spent building the asset and nothing about the interest accruing inside it. If leadership only ever sees the capitalized asset, they are looking at the principal and none of the interest — the exact blind spot the metaphor warns about, now with an auditor's blessing.
Every loan gets one verdict: refinance, pay down, or default
A portfolio is not a to-do list of things to fix. It is a set of positions, and each one gets a decision. There are only three, and the discipline is in saying which out loud rather than defaulting to a vague intention to get to it someday.
- Refinance. Pay a bounded one-time cost to lower the recurring interest without retiring the principal. An adapter in front of the system nobody wants to rewrite, a facade that contains the blast radius, a schema view that lets new work stop paying the old tax. You still owe the balance; you have just dropped the rate. This is the highest-leverage move on high-touch debt, and the one teams skip because it feels like a half-measure. It is not a half-measure. It is the move a treasurer makes every day.
- Pay down. Retire the principal — the rewrite, the migration, the deletion. Expensive, and correct exactly when the interest rate is high enough that you earn the payment back in recovered velocity inside a horizon you can name. The test is not "is this bad." Everything is a little bad. The test is "will paying this off return more capacity than the payment costs, soon enough to matter." If you cannot state the payback, you are not paying down debt. You are indulging a preference.
- Default. Decide, deliberately and on the record, to stop paying — and stop touching. Freeze the subsystem, wrap it in a boundary, route new work around it, and let it sit. Default is not failure; it is the correct answer for low-touch debt with a scary-looking balance. The mistake is defaulting by accident — carrying a loan you have neither restructured nor retired nor consciously parked, paying interest on it every sprint because no one ever decided anything.
One category does not belong on this ledger at all. Some of what teams file under debt is not debt — it is code shipped into production that no accountable human actually understands, which is a control failure, not a loan you chose to take. You do not refinance that; you gate it so it stops arriving. That is a different essay. The point here is only that the loan framing is for the debt you took on with your eyes open, not for the accountability gaps you let through by accident.
What to put in front of the board
Stop asking for time to clean up the code. Report the interest instead. Measure the velocity tax where it already leaves fingerprints, roll it into a single debt-service ratio that trends, and price each loan by the rate it charges rather than the size of its balance. Then bring the board three columns — the loans you propose to refinance, the ones you propose to pay down with a stated payback, and the ones you are choosing to default on — and let them do the one thing a board is for, which is deciding where the capital goes.
I am curious how others are measuring the interest specifically — whether you have found a debt-service ratio your board actually holds onto, or a proxy that trends without pretending to a precision it does not have. Tell me what you are reporting, and what finally got funded.
