Contents
- Why “technical debt” loses the room
- The four numbers
- The 7-slide outline
- The three objections you will get
- How a risk register becomes board evidence
- FAQ
- Next step
Your board does not disbelieve you. That is not the problem.
The problem is that you are asking for several hundred thousand dollars against a category of spending they have no framework for evaluating, presented in a vocabulary that sounds like an engineering preference. They are not refusing. They are declining to decide, which looks the same from where you’re sitting and is a completely different failure.
This is the outline that gets decided.
Why “technical debt” loses the room
The metaphor was a gift to engineers explaining a tradeoff to each other. It is a liability in a boardroom, for three specific reasons.
Debt implies a choice somebody made. Boards hear “debt” and think about a decision that was taken deliberately, which invites the question of who took it and whether they were right. You have now made your funding request into an accountability conversation. That conversation does not end in a budget approval.
Debt implies scheduled repayment. Financial debt has terms. The board’s instinct is that this can be serviced over time, incrementally, out of the existing budget. That instinct is wrong about software and entirely reasonable given the word you chose.
Debt sounds voluntary. It sounds like something you could keep carrying. Boards are comfortable carrying debt — it’s what leverage is.
Say unpriced liability instead.
A liability is something that exists on your balance sheet whether or not anyone chose it. It has a magnitude someone should have quantified. And “unpriced” is an implicit criticism of the reporting, not of the engineering — which puts the board’s attention where you want it, on the fact that they have been making decisions without a number.
That single substitution changes the meeting more than any slide will.
The four numbers
Boards fund things with magnitudes attached. Four numbers do the work, and each has a defensible source inside your own company.
1. Revenue at risk
Not “the system might fail.” The specific revenue that stops if a named component does.
How to source it: take your top three revenue-generating paths. For each, identify the component that would halt it. Multiply your revenue through that path by a realistic outage duration — not worst case, your actual mean-time-to-recovery from the last three incidents.
How to state it: “$X of quarterly revenue flows through a component with no automated tests and one person who understands it.”
That sentence is a board item. The same fact stated as “the payments service has poor test coverage” is not.
2. Cost of the status quo, per quarter
The money you are already spending. This is the strongest of the four because it is not a forecast.
How to source it: fully-loaded engineering cost × the share of capacity going to unplanned work, incidents and workarounds. Your ticket system has the numerator. HR has the denominator.
How to state it: “We are spending $X per quarter maintaining a system we have already decided to replace. That figure has grown from $Y over eight quarters.”
The trend line matters more than the absolute number. A board can rationalize a cost. A board cannot easily rationalize a cost with a slope.
3. Compliance and insurance exposure
Specific and dated, or leave it out.
How to source it: your last security questionnaire from an enterprise prospect, your cyber insurance renewal questionnaire, your most recent SOC 2 or equivalent observations, and — the one people forget — deals your sales team lost or stalled in security review. Sales already tracks this as a deal problem. Reframing it as a system problem is often the single most persuasive slide you have.
How to state it: “Three enterprise deals worth $X stalled in security review last year. Our cyber renewal now asks a question we cannot answer truthfully.”
4. Engineering attrition cost
Quiet, large, and already in your finance system.
How to source it: engineers who left in 24 months × fully-loaded replacement cost (recruiting, ramp time, lost productivity — typically a meaningful multiple of salary, and your finance team likely has a house figure). Compare your engineering attrition to your company-wide rate.
How to state it: “Engineering attrition ran X points above company average for two years. At $Y replacement cost, that is $Z — and the exit interviews say ‘new opportunity’ because the true answer is harder to say.”
A caution worth heeding: use this number, but don’t lead with it. A board that hears attrition first may conclude the problem is management rather than architecture. Place it third or fourth, after the revenue and cost numbers have established the frame.
The 7-slide outline
Seven slides. Not fifteen. A board’s attention for a topic outside its expertise is shorter than you think, and every additional slide is another opportunity to be asked a question that derails you.
Slide 1 — The liability, in one sentence and one number. “$X of quarterly revenue depends on a system we cannot safely change.” Nothing else on the slide. Let it sit.
Slide 2 — What it costs us per quarter, with the trend. Number 2 above, as a line going up over eight quarters. This is the slide that does the most work, because it’s historical fact rather than forecast.
Slide 3 — What has already happened. Three concrete events: an incident, a stalled deal, a departure. Dated, specific, already known to at least one person in the room. You are not predicting a future; you are naming a pattern they have each seen one piece of.
Slide 4 — What happens if we do nothing for four more quarters. Extend slide 2’s line. State the assumption openly. Add the one dated compliance or insurance item from number 3. Do not catastrophize — a measured projection is more alarming than a dramatic one, and it survives cross-examination.
Slide 5 — The options, with costs. Three, priced, with calendar time. Include “do nothing” as option one with its cost from slide 4 — this reframes the decision from “spend money or don’t” to “choose which cost to accept.” published price bands for each option
Slide 6 — The recommendation and what it buys. One option, and the specific capabilities the company gains. Not “modern architecture” — “ability to ship the pricing changes sales has been asking for since Q2.”
Slide 7 — What you’re asking for today. Frequently this should not be the full program. Asking for a $18K–$35K diagnostic with a defined deliverable is a far easier first yes than $400K, and it converts your credibility problem into a document problem. A board that has approved a small thing and seen it deliver approves the large thing much more readily.
The three objections you will get
“Can’t we do this incrementally, alongside feature work?”
The honest answer is usually no, and the reason is capacity, not principle. If unplanned work is consuming a large share of your sprint capacity, incremental improvement is voluntary work — and voluntary work is the first thing an incident-driven team stops doing. You have been trying incrementally. Slide 2’s line is the evidence of how that went. the capacity threshold where incremental stops being possible
“What’s the ROI?”
Resist the urge to invent one. A fabricated ROI gets challenged, and then you’re defending a made-up number instead of a real liability.
Reframe: this is insurance and cost avoidance, not an investment with a return. “The return is that the $X per quarter we currently spend on unplanned work goes down, and the $Y of revenue currently at risk stops being at risk.” That is a real financial argument and it survives scrutiny in a way an invented IRR does not.
“How do we know this estimate is right?”
The strongest possible answer is that you don’t, and here is what would make it right.
This is where the diagnostic pays for itself twice. “This estimate is our internal judgment. A fixed-scope audit produces an architecture map and a risk register from an outside party, and a fixed-price proposal against it. That costs $X and takes three weeks.” You have just converted “trust me” into “verify me,” which is the only move that reliably works with a skeptical board.
How a risk register becomes board evidence
The difference between an engineering opinion and board evidence is authorship and format.
A risk register from an outside audit gives you three things your internal document can’t:
A third party’s name on it. Not because you’re less competent — because you’re not disinterested, and everyone in the room knows it. An outside assessment removes the incentive question entirely.
Severity scoring against a stated scale. Boards are fluent in risk registers; it’s the same format the audit committee sees quarterly. Handing them a familiar artifact removes translation work.
Business consequences, not technical descriptions. “No automated verification that invoices are correct; a pricing change carries an unbounded chance of mis-billing with no detection before a customer notices” is a board item. “Insufficient test coverage in billing” is an engineering complaint. Identical finding.
The register also solves your sequencing problem. When the board asks “why this first,” the answer is a documented dependency chain rather than your judgment.
FAQ
How do I get budget approved for technical debt?
Stop calling it technical debt. Present it as an unpriced liability with four quantified numbers: revenue at risk, cost of the status quo per quarter with its trend, compliance and insurance exposure, and engineering attrition cost. Then ask for a small, defined first step rather than the full program.
What should a technical debt business case include?
Seven slides: the liability in one sentence with one number; quarterly cost with an eight-quarter trend; three things that have already happened; a projection of four more quarters of inaction; three priced options including “do nothing”; the recommendation and what it buys; and the specific ask.
What’s the ROI of fixing technical debt?
Framing it as ROI is usually a mistake. It’s cost avoidance and risk reduction, not an investment with a return. The defensible version: current quarterly spend on unplanned work goes down, and revenue currently at risk stops being at risk. An invented ROI figure will be challenged and you’ll end up defending arithmetic instead of a liability.
How do I answer “can’t we do this incrementally?”
With capacity data. If a large share of sprint capacity is consumed by unplanned work, incremental improvement is voluntary work, and voluntary work is the first thing an incident-driven team abandons. The eight-quarter cost trend is the evidence that incremental has already been tried.
Should I ask for the whole budget at once?
Usually no. A $400K ask from an engineering leader whose credibility is the thing being evaluated is a hard yes. A $20K–$35K diagnostic with a defined deliverable, from an outside party, is a much easier one — and it converts a credibility problem into a document problem.
Next step
Gather the four numbers this week. Every one of them lives in a system you already have: ticketing, HR, finance, CRM.
If the third objection is the one you’re most worried about — “how do we know this estimate is right” — a Systems Audit answers it with a third party’s name on the document. $18K–$35K, two to three weeks, and you own the architecture map, risk register, remediation plan and fixed-price proposal regardless of what you do next.
