How to Put a Dollar Figure on It for Your Board
Steele Consulting
The slide that keeps getting cut
Every CTO we work with at the mid-market level has had the same experience. Two weeks before the board meeting, finance asks for the engineering deck. The CTO has been agonizing over how to talk about tech debt — the brittle billing service, the framework that’s three major versions behind, the duct tape under the customer portal. They draft a slide. Maybe two.
By the morning of the meeting, those slides have been cut.
The reason is almost never that the board doesn’t care. The reason is that the slides don’t speak the board’s language. “We have significant technical debt” is not a financial statement. “Refactoring the platform will take six months” is not an investment case. Boards approve millions in capex on warehouse expansions and CRM migrations because someone walked them through the dollars. Tech debt rarely gets that treatment, and so it stays in the basement, accumulating interest, until something breaks and a calmer conversation becomes a crisis one.
This post is about how to fix that — specifically, how to put a defensible dollar figure on tech debt and walk a board through it. We use a model with our clients called DRIFT, and we have yet to find a category of tech debt that doesn’t sit inside one of its five buckets.
Why most tech-debt conversations stall
Before the framework, a quick diagnosis of why the usual pitch fails:
- It’s framed as engineering hygiene, not financial risk. Boards don’t fund hygiene. They fund returns and they fund risk mitigation.
- The numbers are missing or hand-wavy. “It’s slowing us down” is true and useless.
- There’s no comparison case. A board cannot evaluate a number in isolation — they need a contrast with the cost of doing nothing.
The DRIFT model exists to fix all three at once. It turns a fuzzy engineering concern into five line items, each with a calculable annual cost.
The DRIFT Framework
DRIFT stands for the five ways tech debt quietly drains money from a mid-market company:
- D — Delivery Drag: features ship slower than they should
- R — Reliability Tax: incidents, downtime, and on-call burden cost real money
- I — Innovation Tax: opportunities you can’t pursue because the foundation can’t carry them
- F — Friction Cost: people work around bad systems instead of with them
- T — Talent Tax: good engineers leave, and the ones you hire ramp slowly
Each one becomes a single line on a board slide. Here is how to size them.
D — Delivery Drag
Estimate the percentage of engineering capacity lost to working around old code: branching headaches, broken local environments, fragile tests, deploys that require manual steps. With our clients, the honest answer is usually somewhere between 15% and 30% in companies that haven’t invested in platform work for two or more years.
Annual engineering payroll × % capacity lost = Delivery Drag
For a 40-engineer org with a fully-loaded cost of $200K per engineer and a 20% drag, that’s $1.6M a year in salary funding work that shouldn’t need to happen.
R — Reliability Tax
Pull the last twelve months of incidents. For each incident, estimate three things: engineering hours spent responding, revenue impact if customer-facing, and any SLA credits issued. Add a small but real number for the cost of on-call itself — burnout, weekend hours, the productivity hit on Monday morning.
Incident response cost + revenue impact + SLA credits + on-call premium = Reliability Tax
Most mid-market companies we audit find $300K to $900K a year sitting here, and almost none of it shows up cleanly in the P&L.
I — Innovation Tax
This is the hardest to quantify and the most important to try. Make a list of three to five things the business asked for in the last 18 months that engineering said no to, or estimated at 3× what should have been required. For each, work with finance to model the revenue or savings impact had it shipped.
Sum of (expected value × probability) for foregone or delayed initiatives = Innovation Tax
You won’t get this number to four decimal places. You don’t need to. A defensible range — say, $1M to $3M of foregone opportunity — is enough to make the point that tech debt has a strategic cost, not just an operational one.
F — Friction Cost
This one extends outside engineering. Sales reps maintaining shadow spreadsheets because the CRM integration is broken. Finance closing the books four days late because a report has to be rebuilt by hand each month. Customer support escalating tickets that automation should handle. Count the hours, multiply by fully-loaded cost.
Hours of workaround labor per month × 12 × loaded hourly rate = Friction Cost
Friction Cost is the bucket that turns skeptical CFOs into allies. It’s their people, not engineering’s, whose time is being burned. When you put it on the slide next to the others, the conversation changes.
T — Talent Tax
Tech debt has two effects on hiring. The engineers you most want to keep — the senior ones with options — leave for places that don’t make them maintain a 2017 codebase. And the engineers you bring in take longer to ramp, because the system is harder to learn.
(Attrition cost above baseline) + (Excess ramp time × loaded engineer cost) = Talent Tax
Industry replacement cost for a senior engineer runs 1.5–2× annual salary once you factor recruiting, lost productivity, and onboarding. If your engineering attrition is even three points above your industry baseline, the math gets ugly quickly.
Putting it on the slide
The output of the DRIFT exercise is a single board slide that looks like this:
| Category | Annual Cost | Confidence |
|---|---|---|
| Delivery Drag | $1.6M | High |
| Reliability Tax | $650K | High |
| Innovation Tax | $2.2M | Medium |
| Friction Cost | $900K | High |
| Talent Tax | $750K | Medium |
| Total | $6.1M | — |
Next to it: the proposed remediation investment, the expected reduction in each line item over 18–24 months, and the resulting payback period. Now the board is looking at an investment proposal, not a complaint.
A note on confidence: never present DRIFT as a precise number. Present ranges, label each bucket’s confidence, and show your work in an appendix. Boards respect honesty about uncertainty far more than false precision. The first time a board catches a CTO inflating a number, every future request gets discounted.
The meta-point
The most important thing tech debt does to a company is not slow it down — it is to corrode the language between engineering and the rest of the business. When engineers describe debt and the board hears static, both sides start to believe the other doesn’t understand them. Over enough years, that breaks the relationship. Engineering loses budget battles it should win. The board approves transformation programs that fail because the foundation was never addressed.
DRIFT, or any framework like it, is really a translation device. It takes the work engineers do every day and renders it in the dialect of the board. Once you have that translation, debates that used to feel like religious arguments become spreadsheet conversations. And spreadsheet conversations get funded.
How we use this at Steele Consulting
We typically run a four-week DRIFT assessment with mid-market clients ahead of a major board cycle or before a tech-driven transformation. The output is the board slide above, a remediation roadmap mapped to each bucket, and a quarterly tracking model so the CTO can show the board the number going down over time.
If you’re heading into a board meeting and you don’t yet have a defensible number on your tech debt, that’s the conversation to have now — not after the next incident. Reach out and we’ll walk you through what a DRIFT assessment would look like for your environment.