Every CTO or IT leader I know has the same complaint: they can feel the tech debt dragging their organisation down, they know it needs to be addressed, but they can’t get the board or executive team to prioritise it because it’s invisible on a balance sheet.

That invisibility is the core problem. Tech debt doesn’t show up in financial statements. It doesn’t have a line item in the P&L. It manifests as slower feature delivery, more incidents, higher turnover, and increased costs — but these symptoms are diffuse enough that non-technical leaders attribute them to other causes.

After two decades of having this conversation with boards, I’ve developed an approach to quantifying tech debt that actually works. Here’s the framework.

What Tech Debt Actually Costs

Before you can communicate the cost, you need to measure it. There are four categories of cost that tech debt generates, and all of them can be quantified with data your organisation probably already collects.

1. Developer Velocity Tax

This is the biggest cost and the hardest to see. Tech debt slows down every new feature and change. What should take two weeks takes four because the codebase is tangled, documentation is missing, and developers have to work around legacy constraints.

How to measure it: Track the ratio of time spent on new feature development versus time spent on maintenance, rework, and working around legacy constraints. Most teams can estimate this through time tracking, sprint retrospectives, or commit analysis.

A healthy engineering team spends roughly 70-80% of its time on forward-looking work and 20-30% on maintenance. Teams carrying heavy tech debt often spend 40-60% on maintenance. If you’re paying 10 developers $150,000 each, and they’re spending 50% of their time on maintenance instead of the healthy 25%, that’s $375,000/year in lost productivity.

Tools like LinearB and Jellyfish can help measure engineering metrics that proxy for tech debt impact — cycle time, deployment frequency, and the percentage of work allocated to planned versus unplanned activities.

2. Incident Costs

Legacy systems and accumulated tech debt generate more incidents. Outdated dependencies have known vulnerabilities. Tightly coupled systems create cascading failures. Missing monitoring means issues aren’t caught until customers report them.

How to measure it: Track the number of incidents attributable to legacy systems, the mean time to resolve (MTTR) for those incidents, and the business impact (downtime, lost revenue, customer impact). Your incident management system already has this data.

Multiply the engineer-hours spent on each incident by their loaded cost rate ($100-150/hour for Australian engineering staff). Add the business impact (revenue lost during outages, customer compensation, regulatory penalties). That’s your incident cost of tech debt.

3. Opportunity Cost

This is the most strategic argument. Every month your engineers spend maintaining legacy systems is a month they’re not building the capabilities your competitors are shipping.

How to communicate it: Frame it in terms of product roadmap delays. “The three features we’ve deprioritised for the past two quarters — real-time analytics, mobile app v2, and API platform — represent an estimated $2M in annual revenue opportunity. They’ve been delayed because 40% of engineering capacity is consumed by legacy system maintenance.”

Boards understand delayed revenue. They don’t understand “we need to refactor the persistence layer.”

4. Talent and Hiring Costs

Good engineers don’t want to work on legacy systems with outdated technology stacks. If your stack is COBOL, on-prem Java monoliths, or ancient versions of frameworks, you’ll struggle to hire and retain quality people.

How to measure it: Track your engineering turnover rate and compare it to industry benchmarks. Seek and Hays publish technology salary and attrition data for the Australian market. If your turnover is 5-10% above industry average and exit interviews mention technology stack as a factor, you can calculate the replacement cost (typically 50-100% of annual salary when you factor in recruiting, onboarding, and ramp-up time).

The Board-Ready Presentation

Once you’ve gathered the data, structure it as follows:

Slide 1: Current State Show the four cost categories with dollar amounts. Total them. This is “what tech debt costs us annually.” Make it a single, attention-grabbing number. “$1.8M per year in tech debt costs” hits differently than “we have some legacy systems that need attention.”

Slide 2: Trend Show how these costs have changed over the past 2-3 years. Tech debt compounds — costs should be visibly increasing. If they’re not, you either don’t have a significant problem or you’re not measuring accurately.

Slide 3: Risk Quantify the risk of inaction. What’s the probability and impact of a major incident caused by an unsupported system? What happens if a key dependency reaches end-of-life? Frame these as risk scenarios with dollar ranges, not technical warnings.

Slide 4: The Ask Present a phased remediation plan with costs and expected returns. Don’t ask for a massive upfront investment — ask for a sustained allocation (typically 20-25% of engineering capacity) directed at tech debt reduction. Show the expected reduction in maintenance burden, incident frequency, and velocity improvement over 12-18 months.

Common Objections and Responses

“We can’t afford to divert resources from feature delivery.” You’re already diverting resources — to maintenance and incident response. Addressing tech debt redirects that spending toward work that reduces future costs rather than perpetuating them.

“Can’t we just replace the whole system?” Full system replacements (rip-and-replace) are high-risk, multi-year projects with poor track records. Incremental modernisation — the Strangler Fig pattern — is lower risk and starts delivering value sooner.

“How do we know the investment will pay off?” Define measurable KPIs upfront. Deployment frequency, incident count, MTTR, and the maintenance-to-innovation ratio are all measurable. Report on them quarterly. If the metrics aren’t improving after two quarters, adjust the approach.

“Our competitors aren’t doing this either.” Some of them are. And the ones that aren’t are accumulating the same hidden costs. Being ahead on tech debt management is a genuine competitive advantage — it’s the difference between responding to market changes in weeks versus months.

The Cultural Shift

Getting budget is only half the battle. The other half is changing the culture so tech debt doesn’t accumulate as fast in the future.

This means:

• Making quality a delivery requirement, not an afterthought
• Building refactoring time into sprint plans routinely
• Rewarding engineers who improve existing systems, not just those who build new ones
• Including tech debt assessment in architecture review processes

The organisations that manage tech debt best don’t treat it as a separate initiative. They treat it as a continuous part of engineering practice, like testing or code review. It’s not glamorous, but it’s the difference between an engineering organisation that accelerates over time and one that gradually grinds to a halt.

Boards care about results: revenue, cost, risk, and competitive position. Tech debt affects all four. Your job is to connect the dots with data they can’t ignore.