To explain technical debt to a non-technical CEO, stop talking about code quality and present a delivery and risk cost with a dated ask. A CEO funds paydown when three things are on the page: the debt translated into slower roadmap items, incidents and hiring drag, a request sized in engineer-weeks against your real capacity, and a quarterly report showing what the money moved. It's written for a team of 10-40 engineers. For the wider set of reporting and budgeting topics, see Engineering management guides for CTOs and VPs of Engineering.
Why does "technical debt" not land with a CEO?
Because the CEO hears "the engineers want to rewrite things." The metaphor was meant to say something narrower. Ward Cunningham, who introduced the debt metaphor in his 1992 OOPSLA experience report, wrote that "[s]hipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." He added that "the danger occurs when the debt is not repaid."
Read that again as a CEO would. Debt is a deliberate trade: speed now, cost later. The problem isn't that you took on debt. It's that the repayment never got scheduled, and the interest shows up as features that take longer than anyone expected.
So the CEO doesn't need a definition. They need three things: what the debt is costing the roadmap today, what could go wrong if it stays, and a bounded request they can say yes or no to. Everything below is built to produce those three.
Translate technical debt into commercial risk
Start from your debt register, the list of known items with an owner, a risk and a cost-to-fix. If you don't have one, the CTO's budgeting playbook for debt paydown shows how to build it, including how to score items by blast radius before effort. Don't pitch from a vague feeling that the codebase is messy. Pitch from three items you can name.
For each item, answer one of four questions a CEO already asks:
- Delivery drag. Which roadmap item is slower or blocked because of this?
- Incident and revenue risk. If this fails, what breaks and who notices?
- Hiring and onboarding drag. Does this make new engineers slower to be useful, or hard to hire?
- Security and compliance exposure. Does this block an audit, a certification or an enterprise deal?
Here's how a register item turns into CEO language. Every row is an example with placeholders, not data:
| Debt item (example) | CEO-language effect | Evidence to bring |
|---|---|---|
| Billing module has no tests and one owner | Any pricing change is a <n>-week project instead of <n> days, and a bug hits invoices | Cycle time on the last <n> billing changes, incident count tied to billing |
| Deploys are manual and take <n> hours | Releases batch up, so fixes reach customers late | Deploy frequency, hours per release, time from merge to production |
| Core service is understood by <n> people | Onboarding a new engineer takes <n> weeks before a first change ships | Time to first shipped change for your last <n> hires |
| Unsupported framework version | Blocks a security review that the <named> customer requires | The review date, the version's end-of-support date |
The evidence column is the point. A CEO can't judge your claim about a billing module, but they can read "the last <four> pricing changes took <six> weeks each" if that's what your tracker says. Use your own numbers, and if you don't have one, say the item is a risk you haven't measured yet and make measuring it part of the ask.
How much to ask for at 10-40 engineers
Size it as engineer-weeks per quarter, with the arithmetic visible. Percentages invite an argument about whether 20% is "normal." Weeks don't.
We haven't found a sourced industry percentage for debt paydown, and the companion budgeting guide says the same. Two guides we read, Nebari and monday.com, repeat "15-25% of each sprint," and neither shows where it comes from. Skip it.
The Stripe figure is also not a target. Stripe's 2018 Developer Coefficient survey has respondents estimating that developers spend 13.5 hours a week on technical debt, out of 41.1 working hours, and 3.8 more on bad code. Those are the survey's own estimates from 2018, self-reported. They describe how much time respondents say goes to debt, not how much to fund.
The formula:
ask (engineer-weeks) = sum of <engineer-weeks to fix> for the register items you're proposing
capacity (engineer-weeks) = <engineers> x <weeks in quarter> x <focus factor>
share of capacity = ask / capacityThe focus factor is the fraction of an engineer's week that goes to planned project work after meetings, support and reviews. Measure it from your last two quarters, because we can't give you a sourced number.
A worked example with placeholders only. Say you have 20 engineers, <13> weeks in the quarter and a focus factor of <0.6>. Capacity is 20 x <13> x <0.6> = <156> engineer-weeks. If your three register items cost <8>, <10> and <6> engineer-weeks, the full ask is <24>, or about <15>% of capacity. Swap in your own figures. The point is that the CEO sees how the share was built.
Then offer a choice, not a single request:
Option A (smaller): fix <items>, <n> engineer-weeks, <n>% of capacity
Option B (larger): fix <items>, <n> engineer-weeks, <n>% of capacity
Option C (do nothing): no capacity spent; expected cost = <delay per month> x <months>, plus <named incident risk>Option C matters most. A CEO who sees "do nothing" priced as a monthly delay on a named roadmap item is deciding between two costs, not between engineering and features. Don't size it in euros unless you have a loaded cost per engineer from finance. If you do, multiply engineer-weeks by that figure, and let finance confirm it.
How to write the one-page debt memo
The memo is the whole pitch. One page, sent before the meeting, so the meeting is for the decision.
1. Name the one business outcome at risk
Pick a single outcome the CEO already cares about: the enterprise launch date, the renewal that depends on a security review, the pricing change planned for Q<n>. One outcome, in the first line. Five competing reasons read as a wish list.
2. Show two or three register items in CEO language
Take the strongest rows from your translation table. Keep each to one sentence with its evidence: what slows down, by how much, per your tracker.
3. Price the delay with your own numbers
Use the monthly value of the blocked item, taken from your own plan or finance. Multiply by the months of delay. If no one will give you a value, state the delay in weeks and the date it pushes to. A date is a number a CEO can feel.
4. Give two ask sizes and the do-nothing option
Paste in the A, B and C block from the sizing section. State which you recommend and why.
5. Name the decision and the date
"Approve Option A by <date> so work starts in sprint <n>." A decision with no deadline gets deferred. Add a review date and what you'll report then.
A skeleton to adapt:
Decision needed: approve Option <A/B> (<n> engineer-weeks, <n>% of Q<n> capacity) by <date>
Outcome at risk: <one business outcome>, date <date>
Why: <item 1 in CEO language, evidence> | <item 2, evidence> | <item 3, evidence>
Cost of delay: <blocked item> slips <n> weeks to <date> per month of waiting
Options: A <items, weeks> | B <items, weeks> | C do nothing: <cost>
Recommendation: <option>, because <one sentence>
Review: <date>, we'll report <target metric> moved from <baseline> to <target>The two objections you'll get
"Why didn't you build it right the first time?" Because speed was bought deliberately. Cunningham's point is that a little debt speeds development as long as it's paid back. In our view, shipping to learn what customers wanted was the right call. The failure would be taking on debt and never scheduling the repayment, which is what this memo schedules.
"Can't AI fix it?" Partly, and with a caveat you should have ready. DORA's 2024 report found AI adoption "significantly increases individual productivity, flow, and job satisfaction. However, it also negatively impacts software delivery stability and throughput." In our view, AI can speed up the paydown work itself, such as writing tests around an untested module. It doesn't remove the need to schedule the work, and AI output accepted without proper review can add debt. We'd say use it to shrink the engineer-weeks in your estimate, and only once you've measured that it does.
Report progress so the CEO keeps funding it
Funding gets renewed on evidence. Three lines each quarter, in the same order every time:
Capacity: <n> of <n> engineer-weeks spent (<n>% of the ask)
Metric moved: <target metric> from <baseline> to <current>
Next: <next register item>, <n> engineer-weeks, starts <date>Pick the target metric when you write the memo, not afterwards. Lead time for changes on the blocked item, change failure rate, incident count tied to the module, or time to first shipped change for new hires all work. What each DORA metric measures covers lead time for changes and change failure rate if you're not tracking them yet.
Avoid vanity metrics. Lines refactored, tickets closed and test coverage percentages tell a CEO nothing about the outcome they were promised. If the metric didn't move, say so and say why. A CEO who sees a missed number reported plainly is more likely to fund the next item than one who finds out later.
Then fold these three lines into your regular reporting rather than creating a second channel. What to put in the board update covers the layout, and we'd slot the debt lines into its capacity and reliability items.
What this means for your next budget conversation
You're deciding where the next quarter's capacity goes: debt paydown, features, or more people. Our judgment is to walk in with a sized, dated ask and the do-nothing cost, because a CEO can only decide between options that are priced.
If the answer is "we can't spare the capacity," that isn't the end of the conversation. It means the real choice is between delaying the roadmap and adding capacity, and you should say so plainly. A senior hire that owns the paydown is one way to add it, and the cost-of-delay figure from your memo is already half of that case. A business case template for a senior hire shows how to compare that route with AI seats and contractors.
Keep the two requests separate. Mixing a paydown ask with a headcount ask in one memo gives the CEO an easy way to say no to both.
FAQ
How much of engineering time should go to technical debt?
We don't know of a sourced benchmark, so set it from your own register and capacity, using the formula above. The Stripe survey's 13.5 hours a week is what respondents estimated the average developer at their company spends addressing technical debt, and it dates from 2018. It describes time spent, not a recommended allocation. The 15-25% figure repeated in some guides comes without a stated basis.
How do you quantify technical debt without code metrics?
Use delivery evidence your tracker already holds: cycle time on items that touch the problem area, incidents traced to it, deploy frequency, and time to first shipped change for new hires. Pair each register item with one of these, as in the translation table. If you have none, make collecting it a line in the ask.
Should the CEO or the CTO own the debt decision?
Split it. The CTO owns the register, the estimates and the recommendation, because they're the only person who can judge the technical risk. The CEO owns the trade against the roadmap, because capacity is a company decision. The guide to managing technical debt in a budget covers sign-off and review cadence in more detail.
Does AI-assisted coding increase technical debt?
The evidence we can cite is narrower than the claim. DORA's 2024 report links AI adoption to higher individual productivity but lower delivery stability and throughput. We'd treat that as a reason to track change failure rate and review load while you adopt it, not as proof that AI adds debt.