Last updated: August 19, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
Selling tech debt to executives fails because the phrase names four unrelated problems at once. Split it into security exposure, delivery cost, key-person risk, and a growth ceiling, then bring the one your CFO already funds.
I have watched the same request get denied and then approved inside a single quarter, with no change to the actual engineering work. The only thing that changed was the name on the slide. That is not a story about persuasion tricks. It is a story about a word that stopped meaning anything specific about fifteen years ago, and about what happens to a budget line when nobody in the room can define it the same way twice.
The Only Budget Request That Opens With an Apology
Every other funding ask in the company describes a future gain. Sales wants headcount to close more revenue. Marketing wants program dollars to fill the top of the funnel. Facilities wants a lease that supports the hiring plan. Each of those requests points forward.
Tech debt points backward. The word itself says we borrowed, which means we already spent your money, and now we would like more money to cover what we did with the first batch. You can dress that up. The CFO still hears an overdraft notice. Every time.
I am not being cute about this. I have sat in the chair where the request gets made and I have sat next to the people who decide, and the tell is always the same: the room goes quiet in a way it does not go quiet for a hiring request. Nobody wants to be the executive who says out loud that they are funding somebody’s cleanup. So the ask gets deferred, politely, into a quarter that never arrives, and eighteen months later the same team is making the same request with worse numbers behind it. The work was always legitimate. The framing did the damage. All of it.
This is the funding half of an argument I made earlier about operational discipline and why executives keep cutting it. That piece was about defending the boring work once it exists. This one is about naming it well enough that it gets funded in the first place.
The Word Was Never Supposed to Mean This
Ward Cunningham coined the debt metaphor to describe something narrow and deliberate. You ship a first version knowing your understanding of the problem is incomplete, you learn from what real users do to it, and you go back and repay the simplification quickly. Debt taken on purpose. Repaid on a schedule. That was the whole idea.
What the industry did with it was stretch it over every unpleasant thing in a codebase. Bad architecture. Rushed work. A framework that hit end of life while nobody was watching. One engineer’s opinion about another engineer’s naming conventions. All of it got filed under the same two words. A term that covers everything stops carrying information. It becomes noise.
Here is the part I find genuinely interesting. The one place the term got a precise definition and real money attached to it was not a startup or a consultancy. It was Congress. Section 835 of the fiscal 2022 National Defense Authorization Act put a statutory definition on the books for Department of Defense software, and the Software Engineering Institute at Carnegie Mellon applied it directly in their 2024 recommendations: “an element of design or implementation that is expedient in the short term, but that would result in a technical context that can make a future change costlier or impossible.”
Read that twice. Costlier. That word is the entire pitch, and it is the word that falls out of the conversation the moment somebody says “tech debt” instead.
Four Problems Wearing One Name
When I go into an engineering organization and pull apart what the team has been calling tech debt, I have never once found a single problem. I find four, in some mix, and each one belongs to a different executive with a different budget and a different reason to care. Lumping them together is what guarantees that none of them get funded, because the one person who has to say yes cannot tell which of their concerns you are actually addressing.
| What engineering calls it | What it actually is | Who already has a budget for it |
|---|---|---|
| Old dependencies, unpatched frameworks, end-of-life runtimes | Security and compliance exposure with a published remediation clock | CISO, chief risk officer, whoever signs the audit response |
| Everything in this area takes three times longer than it should | Cost per feature, and therefore how much roadmap a quarter actually buys | CPO and CFO, in the roadmap planning cycle |
| Only one person understands that service | Continuity risk concentrated in a single employee | COO and the head of people, usually already funding retention |
| It works now but it will not hold at volume | A ceiling on the growth number the board was already promised | CEO, and anyone who owns the growth plan |
Take them one at a time. They do not behave alike. They should not be pitched alike either.
Unsupported Components Are Not Debt. They Are a Dated Obligation.
Easiest rename in the set. Also the one engineering leaders skip most often, which still surprises me. CISA maintains a public catalog of known exploited vulnerabilities. As of August 18, 2026, it lists 1,670 entries. Not theoretical vulnerabilities. Confirmed exploitation. In the wild.
Federal agencies have to act on it. For years the governing rule was Binding Operational Directive 22-01. One flat clock. Two weeks for a recent CVE, six months for an older one. CISA revoked that directive on June 10, 2026 and replaced it with Binding Operational Directive 26-04, which sets the deadline from four variables instead of one: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether an attacker can automate the exploit, and how much control they gain if it works.
Sit with that change for a second, because it is the whole argument of this piece playing out in federal policy. The government had one blunt label and one blunt clock. It replaced both. What it built instead names the four things that actually drive the risk. Your company is almost certainly not bound by either directive. Does not matter. What matters is that somebody outside your building has published a dated, tiered obligation for the exact class of problem sitting in your dependency file, and you can put that framework on a slide.
“We are carrying tech debt in our payment libraries” gets nodded at. “Three of our vendor connections run on a library version carrying a CVE that CISA lists as actively exploited, and two of those three are publicly exposed, which is the top tier of the federal remediation schedule” gets a meeting on the calendar by Thursday. Same work. One of those sentences has an external authority and a tier in it.
Cost Per Feature Is a Number Product Already Tracks
Product leaders think in roadmap capacity. They have a list, they have four quarters, and they are constantly deciding what falls off the bottom. Tell that person you need a sprint for tech debt and you have asked them to delete a feature so you can do something invisible. Of course they say no. You would too.
Give them the arithmetic instead. Pull the last ten tickets that touched the problem area and the last ten that did not, compare the elapsed time honestly, including the review and the rework, and you will usually find a multiple sitting there in plain sight. Then the ask converts. It stops being a sprint you are taking away from the roadmap and becomes a purchase of roadmap capacity you do not currently have. Product leaders buy that. It is the only currency they trade in. Nothing else registers.
The One-Person Problem
Every organization has a service that exactly one engineer can safely change. Everybody knows who it is. Nobody writes it down where an executive would see it. It feels like an accusation against someone who has done nothing wrong and is in fact the only reason the thing still works.
Say it out loud anyway, in continuity language, because that is what it is. One resignation and a two-week notice period, and a system that touches revenue has no qualified owner. That is not an engineering complaint. That is an operational risk with a named single point of failure, and the executives who own business continuity planning have a budget line for exactly that shape of problem already. KORE1 has been placing engineers across more than 30 U.S. metros for two decades and holds a 92% twelve-month retention rate on those placements, and the pattern their software engineering staffing team keeps seeing is that the concentration is discovered during the exit interview rather than during planning. That is the expensive way to find out. Much too late.
The Ceiling You Already Promised the Board
This one only works if the growth number is real. When it is real, nothing else in the set comes close.
The board has been promised something. Double the volume, a new segment, a partner channel that triples the transaction count. Somewhere under the hood is a component that holds at today’s numbers and does not hold at those numbers, and you probably know exactly which one it is. Frame the work as the thing standing between the company and a commitment it has already made publicly, and you are no longer asking for cleanup money. You are pointing at a gap in a plan that other people own. That is a very different conversation, and it is one I have watched turn a nine-month deferral into a funded workstream in about ten days, because at that point the delay belongs to somebody with more pull than you.
Why the Name Changes the Answer
There is a temptation to treat all of this as spin. It is not. The research on decision-making is unusually clean here.
Amos Tversky and Daniel Kahneman published The Framing of Decisions and the Psychology of Choice in Science in 1981. Their finding was that people presented with mathematically identical choices reverse their preference depending on whether the outcome is described as a gain or a loss. Same numbers. Same odds. Different words, different decision. This holds for trained professionals. It holds for people who know about the effect and are actively watching for it.
So when an engineering leader describes maintenance work as debt, meaning a liability created by past choices, and a CFO evaluates it against a request from sales described as future revenue, that comparison was decided before anyone opened their mouth. The engineering ask is a loss frame. The sales ask is a gain frame. The framing effect predicts the outcome. In my experience it predicts it with depressing accuracy.
The second reason is more practical. There is no single number called tech debt. There never will be. The SEI’s 2024 write-up points to a Google effort that explored 117 different metrics across quarterly developer surveys and found that no single metric predicted the reported categories of technical debt. One hundred and seventeen. The conclusion was that no generalizable measure exists for it.
Sit with what that means for a budget conversation. Your CFO’s entire job is comparing quantified requests. You are bringing them a category that the best-instrumented software organization on the planet could not reduce to a number. They are not being obtuse when they push back. They are being consistent.
The four renames work because each one lands on a thing that is already counted. Days to remediate. Cycle time on a ticket. Headcount concentration on a system. Transactions per second against a committed growth target. Nobody has to invent a measurement. Which means nobody has to defend one.
The Sentence That Gets Funded
After enough of these meetings I stopped writing decks first. I write one sentence. If the sentence does not hold up, no deck saves it.
The sentence needs four things. A named system, not a layer or an area. A consequence with a unit attached, whether that unit is dollars, days, or a count of people. A date or a clock that came from somewhere other than engineering. And the name of the person who owns the decision, which is often not you.
Compare these. “We need to address technical debt in the servicing platform.” That is the version that gets deferred, and I have written it myself more times than I would like to admit.
Against: “The payoff quote service can be changed by one engineer, takes nine days per release cycle instead of two, and blocks the partner integration we announced in January. Fixing it is roughly six engineer-weeks. The person who needs to approve the tradeoff is the CPO, not you, and I have already walked them through it.”
That second sentence is unpleasant to write. Genuinely unpleasant. It requires you to have actually measured something, to name a colleague’s commitment out loud, and to admit you are not the decision maker. Every part of that is harder than saying “tech debt.” That difficulty is the point. The reason the phrase survives is that it lets an engineering leader raise a concern without doing the work of specifying it, and executives have learned to hear it as exactly that.
One caution on the estimate you attach. Put a range on it and name what the range depends on, the same way you would in any other planning conversation. I laid out why that matters in the sprint plan that acts like a contract. A precise number you cannot hold is worse than a range you can.
Where the Rename Turns Into Spin
Now the part where I argue against myself. A renaming playbook in the wrong hands is just a vocabulary for getting money you did not earn.
The rename only works when the underlying claim is true and checkable. Both words matter. If you tell a CFO that a component blocks the growth plan, and then the growth plan slips for four unrelated reasons and your component never turns out to matter, you have not lost one budget request. You have taught a finance executive that engineering renames things when it wants money. You get one of those. The next honest request you bring, on a genuine security exposure with a real date, will get read as marketing, and you will have earned that.
There is a related failure I see more often. A leader renames the problem correctly and then cannot answer the obvious follow-up: why now, and what happens if we wait two quarters. If the honest answer is “nothing much,” say so and take it off the list yourself. Cutting your own request is the single most credible thing you can do in that room, and it costs you almost nothing, because the requests you keep get taken seriously from that point forward in a way they simply were not before.
And sometimes the diagnosis is wrong before the naming ever starts. A team that feels slow is not always carrying a structural problem. Sometimes it is carrying people who are tired, and no amount of refactoring fixes that. I wrote about telling those two apart in how to tell if your engineering org is actually slow. Rename the wrong problem well and you will get funded for the wrong work, which is a worse outcome than being denied.
Where fear of the code is the real driver rather than any measurable cost, that is its own failure mode with its own fix, and I took it apart separately in why engineering orgs end up afraid to touch their own code.
What Gets Asked in the Budget Meeting
Is this not just relabeling the same request to trick the CFO?
No, because the four renames each require evidence the original phrase never did. You cannot say “security exposure with a two-week clock” without producing the CVE and the date.
Relabeling would be swapping one vague term for a nicer vague term. That fails immediately, and it should. Split tech debt into its four real components and something else happens. Three of them turn out weaker than you assumed. One turns out far stronger than what you had been pitching. The split is a diagnostic before it is a pitch, and most of its value shows up well before you get to the meeting.
Our exec team already uses the term. Do I really have to stop?
Keep it in conversation, drop it from the ask. The phrase is fine as shorthand between people who share context and useless the moment money is attached to it.
I do not fight the vocabulary. Fighting it makes you sound like a pedant. The executives using the phrase are not wrong to use it. They are using the word the industry handed them. What I do is refuse to let it appear on the line item. Talk about tech debt all day in the hallway. When it goes on a slide with a dollar figure next to it, it needs a real name.
Which of the four should I lead with?
The one with an external clock. Compliance dates and publicly announced commitments beat internal measurements every time, because nobody in the room can negotiate with them.
Delivery cost is the most common and the weakest opener, because it depends on numbers your own team produced, and a skeptical CFO can discount those numbers without being unreasonable. Lead with whatever came from outside the building. A regulator, a federal catalog, an auditor’s finding, or a partner contract with a go-live date. Then bring the internal arithmetic as support once the room already agrees something has to move.
What if the real answer is that we made bad decisions and now we have to pay for them?
Then say that, once, without flinching, and move immediately to the number. Executives forgive a past mistake far more readily than they forgive a request they cannot evaluate.
There is a version of this conversation where a leader tries to hide the origin, and it always reads as evasion. Own it in one sentence. One. “We chose speed over structure in 2024 to hit the launch, that was my call, and here is what it costs us per release now.” I have seen that land well. What does not land is a lengthy defense of the original decision, which nobody asked for, followed by a request with no number in it.
How long before this actually changes anything?
One planning cycle, usually. The rename is cheap. Producing the evidence behind it takes two to three weeks, and that is the part people skip.
Pulling twenty tickets and comparing cycle times is an afternoon. Mapping your dependency versions against the federal catalog is a day. Less with a software bill of materials already in place. Finding out which single engineer is the only safe pair of hands on a service takes one honest conversation with a tech lead. None of it is hard. Just unglamorous, which is precisely why it does not happen until somebody decides that being denied twice was enough.
Say the Real Name First
Pick the request that got deferred last quarter. Do not rewrite the deck. Not yet. Write one sentence that names the system, the consequence with a unit on it, the date, and the person who actually owns the call. If you cannot fill in all four blanks, you have found the reason it was deferred, and it was never the executive’s judgment.
One of the hardest parts of this job is helping people, including senior executives at times, understand that operational discipline is not bureaucracy. It is the foundation that enables great technical work. The naming is part of that discipline. A problem nobody can name precisely is a problem nobody can fund, prioritize, or finish.
If you are heading into a planning cycle with a request that has already been turned down once, I am happy to look at the sentence with you before you bring it back. Connect with me on LinkedIn and tell me which system it is.
And if the honest diagnosis turns out to be the third one, a service with exactly one qualified owner, no amount of reframing closes that gap. KORE1 places senior engineers who can take ownership of systems like that, most often on a direct hire basis. Talk to their recruiting team if the constraint you found is people rather than process.
Related reading: Operational Discipline Is Not Bureaucracy, Load-Bearing Spaghetti: How Engineering Orgs End Up Afraid to Touch Their Own Code, and How to Tell If Your Engineering Org Is Actually Slow (vs. Just Tired).
