If you need to explain technical debt to executives, you’ve probably had this conversation before.

“We need to refactor the authentication module.”

Your CEO stares at you. “What feature does that ship?” You try to explain that it’s not a feature, it’s maintenance, it’s important, the code is getting harder to work with. Their eyes glaze over. “Let’s talk about it next quarter.”

Next quarter comes. The same conversation happens. Nothing changes. Meanwhile, everything takes longer to build, bugs keep recurring in the same places, and your team is frustrated.

The problem isn’t that your CEO doesn’t care about quality. You’re just speaking different languages.

Why “we need to refactor” doesn’t work

Non-technical leadership hears “refactoring” as “the engineering team wants to rewrite code that already works.” From their perspective, that sounds like gold-plating. The product works. Customers are using it. Why spend time and money rebuilding something that isn’t broken?

They’re not wrong to be skeptical. They just don’t have the information to evaluate the request. And the burden of translating is on you, not them.

Three common mistakes engineers make when pitching technical debt work:

Leading with the technical problem. “Our database queries aren’t indexed properly” means nothing to someone who doesn’t know what an index is. Lead with the business impact instead.
Using engineering jargon. “Tech debt,” “refactoring,” “coupling,” “abstraction” are shop talk. Your CEO speaks revenue, cost, risk, and speed.
Asking for time without quantifying the cost. “We need two sprints to clean this up” is a cost with no return. “We’re losing 15 hours per week to workarounds in the billing module” is a cost that justifies investment.

The framework: translate to dollars, risk, and speed

Every technical debt conversation should answer three questions in business terms:

1. What is this costing us right now?

Don’t say: “The code is messy and hard to work with.”

Say: “Features that should take 3 days are taking 2 weeks because developers spend 60% of their time navigating workarounds in module X. At our engineering cost of $Y/hour, that’s roughly $Z per month in lost productivity.”

The key move: convert engineering time into dollars. Your CEO thinks in dollars. If a developer costs the company $80/hour fully loaded, and they’re spending 10 hours per week on workarounds, that’s $3,200/month. For a team of four, it’s $12,800/month. Suddenly “we need to refactor” becomes “we’re burning $12,800 per month on avoidable overhead.”

2. What risk does this create?

Don’t say: “We have technical debt in the payment module.”

Say: “The payment module hasn’t been updated in 18 months. It has 3 known security vulnerabilities. If one of these is exploited, we’re looking at a data breach that triggers GDPR notification requirements and potentially six-figure fines.”

Risk is a language executives understand. Frame technical debt as business risk: security exposure, compliance violations, inability to respond to market changes, key-person dependency (“if Alex leaves, nobody else can maintain the billing system”).

3. What does fixing it unlock?

Don’t say: “The codebase will be cleaner and more maintainable.”

Say: “After this work, the billing features our sales team has been requesting will take 2 weeks instead of 2 months. We’ll also eliminate the recurring payment bug that support handles 15 tickets per week for.”

Connect the fix to something the business already wants. If sales needs a feature, if support is drowning in tickets, if customers are complaining about a bug. Position the tech debt fix as an enabler of business goals, not a standalone engineering project.

A template for the conversation

A structure you can adapt:

“We have a problem in [specific area] that’s affecting [business metric].

Right now, it’s costing us [$ amount or time] per [period] because [concrete impact]. It also creates [risk] if [scenario].

I’m proposing we spend [time estimate] to fix it. After that, we’ll be able to [business outcome] and eliminate [recurring problem].

Here’s the data that shows the impact: [report, metrics, ticket counts].”

That last line is the important one. Executives trust data more than opinions. If you can show a code health report with concrete scores, trend lines, and specific findings, your proposal stops being “the engineering team wants to play with code” and becomes a data-backed business case.

What makes the difference: evidence

The engineering managers who successfully get technical debt budget approved have one thing in common: they bring evidence, not arguments.

That evidence can take many forms:

Ticket data. “These 5 recurring bugs all trace back to the same module. We spend 8 support hours per week on them.”
Velocity metrics. “Our feature delivery rate dropped 30% this quarter. Here’s the correlation with complexity growth in module X.”
Code health reports. An automated analysis that shows health grades, security vulnerabilities, dependency staleness, and team knowledge gaps in language a non-technical executive can read.
Incident history. “We’ve had 3 production incidents in 6 months, all caused by the same area of code.”

The format matters less than the principle: show, don’t tell. A report that says “your security score is 60/100 with 5 known CVEs” is more compelling than “we should probably update our dependencies.”

Common objections and how to handle them

“Can’t we just fix it as we go?” Sometimes. But if the team has been “fixing it as they go” for 6 months and it’s still a problem, incremental improvement isn’t working. Some debt requires a focused effort. Propose a time-boxed sprint, not an open-ended rewrite.

“We can’t afford to pause feature work.” Reframe: you can’t afford not to. If technical debt is making features take 3x longer, every week you delay the fix costs more than the fix itself. Show the math.

“How do I know this won’t just happen again?” Fair question. Propose ongoing monitoring. A monthly or quarterly code health check catches new debt before it compounds. This is where automated analysis tools earn their keep.

“Last time engineering said ‘two weeks’ it took two months.” Acknowledge the trust gap honestly. Propose milestones with visible progress rather than a big-bang delivery. Show intermediate results.

Make the invisible visible

Most technical debt conversations fail not because the CEO doesn’t care, but because they can’t see what you see. You stare at the code every day. You feel the friction. They see a product that works and a team asking for time to do invisible work.

Translate the code into business language. Quantify the cost. Name the risk. Connect the fix to outcomes they care about. Bring data.

When you do that, “we need to refactor” becomes “here’s a $150K/year problem with a $20K fix.” Any CEO will engage with that.

Need data to back your technical debt case? StackGrit produces a project health report with scores, trends, and specific findings your leadership team can read without an engineering degree. First report is free.

Get the report that gets your budget approved →