Sell technical debt to a CEO without talking about code

Why this conversation often fails

CEOs do not approve technical debt work because engineers are tired of a messy codebase. They approve it when they can see what the company is losing by leaving it alone.

That is where many teams miss. Engineers talk about hacks, brittle services, old frameworks, or the part of the system nobody wants to touch. All of that might be true. It still does not answer the question a CEO is really asking: what does this cost the business?

The problem gets worse when the first thing leadership hears is the price of the fix. If you open with "this will take six weeks," the CEO will compare those six weeks with features, sales activity, hiring, and everything else competing for time. If the payoff is still vague, the answer is usually no.

Abstract language also hurts the case. "Technical debt" is too broad. "Every billing change adds two extra QA days" is concrete. So is "support tickets spike every time we touch checkout" or "this issue delayed a launch by a week." Those are business problems. They have a cost, an owner, and a deadline.

The conversation changes when you name the risk in plain language. "This part of the system slows releases, adds support cost, and raises the chance of a customer facing outage" is something a CEO can act on. Now you are not asking for trust. You are asking for a decision.

What a CEO cares about first

Most CEOs sort problems by business damage, not by how ugly the code looks. If revenue is fine, support is quiet, and launches still happen on time, they will spend money elsewhere.

That is why words like "refactor" and "cleanup" usually fail early. Start with the effect instead.

Revenue risk gets attention fastest. A flaky checkout, broken signup flow, missing invoices, or a bad outage during a sales push can lose money in a single day.

Support cost is close behind because it is easy to see. If one bug creates 40 tickets a month, that is payroll, slower response times, and frustrated customers. It is no longer just a product issue.

Shipping speed matters more than many engineers expect. When every release needs hand fixes, extra testing, or late night patching, new work slips. A launch planned for this month moves into next month. Revenue moves with it.

Then there is the quieter loss: internal time. Engineers spend hours tracing old bugs, rerunning failed jobs, fixing data by hand, and redoing work after fragile deployments. That time never shows up on an invoice, but the company still pays for it.

A CEO will usually listen when you frame the problem in numbers they already track:

• money lost or delayed
• support hours spent each week
• release dates that slipped
• engineering time burned on repeat fixes

Tie one technical problem to one business result and the discussion gets easier fast. "This billing bug costs two support hours a day and slows finance close" is much stronger than "our codebase needs cleanup."

Pick the debt that hurts the business now

Do not walk into the room with 40 cleanup tasks. Pick one problem, or two at most, that already hurts the company in a way everyone can understand.

Start with the area that costs money, creates visible support load, or delays releases. Leave the rest for later. A broad pitch feels vague. A narrow problem with a recent bill attached feels real.

Fresh evidence matters more than old complaints. Use examples from the last few weeks or months: an outage that blocked signups, a refund after a broken workflow, or a feature that slipped because the team spent three days untangling an old module. Recent pain is easier to fund.

Bring proof from teams outside engineering when you can. Support often has the clearest signal because they see repeat tickets. Sales can confirm when a bug stalls deals. Product managers know which releases keep slowing down because the same fragile area breaks every time.

A few notes are enough: two or three recent incidents, any refunds or credits tied to them, support hours spent on repeat issues, and deadlines that moved because this area took longer than expected. That gives leadership a business case, not an architecture lecture.

Skip work whose main benefit is tidier code or a nicer folder structure. That work might still matter, but it is harder to fund when budgets are tight.

A stronger ask sounds like this: "Our billing flow creates about 20 extra support tickets a week, and every change there adds two days of delay. Fixing this part should reduce ticket volume and help us ship pricing updates on time." That is much easier to approve than "we need to refactor billing."

Turn engineering pain into money and time

A CEO does not need to feel the team's frustration. They need to see the cost.

Start with wasted engineering time. Ask a narrow question: how many hours does this problem burn each week? Count bug chasing, manual fixes, failed deployments, retesting, and interruptions from support. If four engineers lose two to four hours a week, that is eight to 16 hours gone. At a loaded cost of $70 to $120 an hour, the business is burning roughly $560 to $1,920 every week.

Then add support and rework. If the same issue creates 15 extra tickets a month, and each ticket takes 20 minutes of support time plus 30 minutes of engineering time, the cost adds up quickly. You do not need perfect finance data. A rough range is enough if you can explain where it came from.

Use simple math that fits in one breath:

• weekly engineering hours lost x hourly cost
• monthly support and rework hours x hourly cost
• release delay x likely deal, renewal, or campaign value
• current monthly cost versus cost to fix

Release delays are often the strongest part of the case. If one old service pushes a requested feature back by four weeks, attach a business number to that delay. Maybe sales cannot close a $12,000 to $25,000 contract this month. Maybe a renewal stays at risk until performance improves. The point is not perfect precision. The point is showing that waiting has a price.

Use ranges when the data is fuzzy. "This issue likely costs us $3,000 to $7,000 a month" sounds more honest than pretending the number is $4,386.

Keep the story short. "We lose about 12 engineering hours a week, support spends another 10 hours a month on the same problem, and one release slipped by two weeks last quarter. Fixing this should take six weeks and likely pays back within a quarter or two." That is a business case, not a code debate.

Build a single page case

Most CEOs will read a page that helps them make a decision. They will not read three pages about architecture.

Open with one sentence that names the problem in business terms. Skip labels like "legacy" unless you explain the effect. A better opening is: "Checkout failures are costing paid orders, creating extra support work, and slowing every release that touches billing." That sentence gives the issue a price instead of a technical label.

After that, show today's cost with three numbers. Three is enough. Pick numbers leadership already cares about, such as lost revenue, support hours, and release delay. If the figures are estimates, say so and keep them conservative.

Then make a small ask. Do not ask for a full rebuild. Ask for a fixed scope with a clear end, like two engineers for two weeks to replace one risky billing module and add tests around it. Bounded work feels safer than an open ended cleanup effort.

Say what should improve after the work. Be specific. Name what you expect to reduce, speed up, or prevent. That makes the proposal easy to judge.

It also helps to say what you will not touch yet. You are not rebuilding the product. You are fixing one expensive weak spot.

If you need a simple shape for the page, use this:

• the business problem in one sentence
• three numbers that show today's cost
• the small fixed scope you want funded
• two or three results you expect after the fix
• one line on what stays out of scope

That is usually enough because it reads like an operating decision, not an engineering complaint.

How to run the meeting

Start with a problem the CEO already feels. Pick one recent example: a checkout bug that took two days to fix, a release that slipped, or a support issue that kept coming back. The opening matters more than any diagram.

Use one story, not a pile of old complaints. Say what happened, who felt it, and what it cost. For example: "Last month's billing issue created 37 support tickets, delayed the new pricing launch by a week, and pulled two engineers off roadmap work." That gives the meeting weight without drifting into code quality talk.

Then ask the question leadership cares about: what does waiting another quarter cost? Put a believable range on the table. Lost upgrades, more refunds, more support time, or one more delayed feature is enough.

Keep the meeting tight. Open with the business issue, name the repeated pattern behind it, put a cost on delay, and ask for a decision.

Give two concrete paths. One is the patch: spend a little now, reduce pain for a while, and accept that the team will keep moving slowly. The other is the root fix: spend more this quarter, remove the repeat problem, and ship faster afterward. Put both on one page. If one option is clearly better, say so.

Do not end with vague interest. End with a decision, an owner, and a date. The CEO can approve the deeper fix, choose the short patch, or ask for one missing number before deciding by Friday. Any of those is better than leaving with "we'll think about it."

A simple example from a product team

Picture a subscription company with a checkout flow that changed too many times in a rush. New offers, coupon logic, payment retries, and quick patches all piled into one fragile area. Sales still come in, so the issue does not look urgent at first.

Then the business impact shows up. Checkout bugs trigger refunds every week. Support gets a steady stream of angry tickets from customers who cannot complete a purchase or see the wrong charge. Nobody on the executive side needs a lesson on code quality to understand that.

Engineering feels the cost too. Two days a week disappear into hotfixes, log reviews, manual checks, and small patches just to keep checkout stable. That is time the team cannot spend on onboarding improvements, pricing tests, or the next feature sales asked for.

Marketing runs into the same problem from another angle. They have a campaign ready, but they delay it because releases feel risky. If they push more traffic into a brittle checkout flow, the company pays twice: more failed orders and more support work.

When the team asks for three weeks to rebuild that one area, they do not talk about cleaner architecture or code style. They explain the business case in plain terms. Refunds and support time are already costing money every month. Hotfix work is eating a large share of engineering time. Release risk is slowing marketing and pushing revenue out.

That framing changes the meeting. Leadership stops hearing "engineering wants cleanup" and starts hearing "we are already paying for this every week."

The numbers do not need to be perfect. Honest estimates work better than fancy math. If three weeks of planned work can stop weekly refunds, cut support load, and make releases safe enough for the delayed campaign, the cost of waiting starts to look higher than the cost of fixing the problem.

That is when approval gets easier. The work is no longer about code purity. It is about protecting revenue and getting the team back to shipping.

Mistakes that weaken your case

Weak pitches usually fail for the same few reasons.

The first is leading with engineering language. If you tell a CEO the code is ugly, inconsistent, or hard to work with, it sounds like taste. Most leaders will not fund "cleaner code." They will fund lower revenue risk, fewer support tickets, and faster releases.

The second is piling together unrelated problems. Ten issues at once do not make the case stronger. They make it hard to follow. Pick the one problem causing the most business pain right now and stay there.

Bad numbers can also hurt more than no numbers. Teams sometimes guess too high because the pain feels obvious to them. Leadership will test the claim fast. If you say a system wastes 40% of engineering time, be ready to show how you measured it. Simple proof is enough: repeated incidents, release delays, support hours on one recurring issue, refunds after outages, or extra time needed to ship a normal feature.

Another common mistake is asking for a huge rewrite with no checkpoint. Months of work without a visible milestone sounds expensive and risky, even when the system is in bad shape. A staged plan is easier to approve. Ask for a small first step, a clear deadline, and one result people can see.

Many teams also forget to show the cost of doing nothing. That leaves the CEO comparing a real bill today against a vague problem tomorrow. Make the tradeoff concrete. "If we leave this alone, support will keep spending 15 hours a week on manual fixes, and the next pricing change will take three weeks instead of four days" is hard to ignore.

Quick checks before you ask

Before you ask for budget or time, make sure you can explain the problem without using code language.

State the risk in one sentence tied to money, customers, or churn. Bring one recent support case with hours, cost, or customer impact. Show slower shipping with dates from actual releases. Ask for a limited first step with a time box. And be ready to answer what waiting will likely cost over the next quarter.

That last part matters a lot. If you cannot explain the cost of doing nothing, the case is still too vague.

What to do next

Start small. Pick one problem people already feel every week, not the messiest part of the codebase. A slow release process, repeat support tickets, or a fragile billing flow is easier to defend than a broad cleanup plan.

Use fresh evidence. Pull examples from the last 30 days so the discussion stays concrete. Count how many support tickets came from the issue, how many engineering hours went into fixes, how often releases slipped, and whether the problem touched revenue or customer trust.

Write the case on a single page before the meeting. Lead with the cost of doing nothing. Then show the work you want funded, the rough effort, the expected gain, and how you will check results after the fix.

A small example usually works best. If login failures created 18 support tickets last month, pulled two engineers into urgent fixes, and delayed a planned feature by four days, say that plainly. Most CEOs react better to "this delayed launch and raised support costs" than "our auth layer needs refactoring."

If your team needs help turning technical risk into a business case, an experienced Fractional CTO can help translate the issue into plain language and cut weak claims. Oleg Sotnikov at oleg.is does this kind of advisory work for startups and small to midsize companies, especially when the problem touches product architecture, delivery speed, infrastructure, or a shift toward AI driven development.

Then ask for a decision on one contained fix, with a clear owner and a review date. One approved win makes the next conversation much easier.