The technical debt business case: How to win sign-off from everyone who can say no

Most engineering teams treat zero technical debt as something to aim for. Josef Bárta, Chief Architect at Revolgy, reads it as a warning sign. A codebase carrying no debt has usually run ahead of the business, which means money went into engineering polish that should have gone into sales, marketing, and winning customers. Some debt is the correct choice.

The harder truth sits one layer down. Engineering almost always knows where the debt is. Josef puts it plainly:

Generally, technical teams are very good at knowing that they have technical debt. Where it breaks down is the communication between the engineering team and the business.

So the CTO’s real problem is rarely finding the debt. It is getting the budget and the calendar time to fix it, from people who do not all want the same thing. That is a business case problem, and it is harder than the engineering itself.

This guide, based on a conversation between Michael Fitzgerald, Solutions Manager at Revolgy, and Josef Bárta, covers why remediation stalls even when everyone agrees the debt is real, the four stakeholders who decide whether it gets fixed, why the case gets harder at the board and after an acquisition, and how to build and finance a case each of them will approve.

Jump to section:

• Why does fixing technical debt stall even when everyone agrees it is real?

• The four people who decide whether technical debt gets fixed

• Why the case gets harder at the board and after an acquisition

• How to build the case each stakeholder approves, and finance it

  • CFO: Turn the debt into a number, then shrink it with outside money

  • CRO: Attach the fix to revenue that is already at risk

  • CPO: Bring a delivery plan, not a freeze

  • Board: Tie it to enterprise value on the exit timeline

• Bring the case to an Architecture Clinic at Revolgy

• FAQs

Why does fixing technical debt stall even when everyone agrees it is real?

The standard advice for a CTO in this position is to stop talking like an engineer and start talking like the business. Speak in revenue, risk, and time. That advice is correct, and on its own it does very little, because it treats leadership as a single audience with a single set of concerns.

That is the mistake. A request to pause part of the roadmap and spend a quarter hardening the foundation lands on several desks at once, and each person reads it against a different scorecard.

• The CFO sees cost and risk on the financials.
• The revenue leader sees a quarter where the product might wobble in front of customers.
• The product leader sees features slipping.

Getting engineering to agree the debt is real is the easy part. Getting these people to agree on the same fix, in the same quarter, is the wall most remediation plans hit.

A single deck addressed to “the executives” tends to die for this reason. It answers a question none of them are actually asking, and it makes each reader translate the ask into their own terms without help. That translation is the CTO’s job, and it has to be done several times, in several languages, before anyone signs.

The four people who decide whether technical debt gets fixed

Remediation of any size has to clear four people, and three of them do not report to engineering. Each carries a specific fear, and each responds to a specific version of the argument.

• The CFO

• the maintenance drag it already imposes,
• the outage exposure it creates, and
• the external funding that can offset the bill.
  

• The CRO

Reads it as a quarter where the product might stumble in front of customers. Their team is “on the receiving end of issues with customers complaining,” as Bárta puts it, which is what turns an abstract engineering concern into churn the CRO can feel. Tie the debt to lost renewals and to the sales team’s ability to keep selling, and the revenue seat becomes an ally instead of an obstacle.

• The CPO

Is the one to watch. On paper, they sit closest to engineering and should be the easiest approval. In practice, they carry the opposite incentive, because hardening the foundation usually means pausing the features they are measured on.

Bárta names it directly: pausing feature work to fix the foundation is something “your CPO is inherently gonna be unhappy about.” The version of the case that wins them is a plan that keeps the roadmap shipping while the repair happens underneath it.

• The board

It is the fourth approval, and it behaves least like the other three. It treats remediation as capital allocation, weighing budget tied up in work with no visible revenue against everything else that money could fund, and its resistance only grows the further the request sits from the code. Winning it comes down to the investment horizon, which the next section works through in full.

The table below maps what stops each stakeholder from saying yes, and what moves them.

Why the case gets harder at the board and after an acquisition

The board runs on the investment horizon

Every level the request climbs, the instinct to leave a working system alone gets stronger. At the board, “if it ain’t broke, don’t fix it” hardens into policy, because directors sit one more step removed from the code and one step closer to the return. Bárta describes the board conversation as “literally a level up” from the internal one, where you are no longer persuading your own executives but presenting a case the board has to approve.

What usually decides the case is timing. Most private equity and venture investors have a rough date in mind for when they will sell the company and take their profit. That date shapes what they are willing to spend on. If the sale is close, they back the features that make the company look more valuable to a buyer and skip the behind-the-scenes fixes. If the sale is years away, they are more open to funding the repair, because they still carry the risk if it breaks.

So the CTO should tie the fix to that timeline. Show how it protects or raises what the company is worth before the sale, in the window the investors actually care about. Framed that way, the board has a reason to say yes that has nothing to do with clean code.

Acquisitions import technical debt and create more of it

An acquisition makes all of this harder, because it multiplies the debt and then buries it. Every company you buy arrives with its own legacy, and merging two stacks generates fresh debt on top. Josef’s summary is blunt: whatever you acquire, whether it is technology, a customer base, or a team, “everything comes with a legacy that inherently comes with its own technical debt but also creates more technical debt.”

The sharper acquirers price this in during due diligence, before the deal closes, and treat integration debt as a line item instead of a surprise. Even then, remediation tends to slide down the list once the deal is done, buried under the workload of merging two organizations and everyone in them.

The debt does not go away. It waits, while the integration consumes the attention that might have addressed it, which is how a manageable problem becomes an expensive one. The CTO who wants that work funded has to raise it while the deal model is still open, because after the final close, it competes with everything else on the integration plan and usually loses.

How to build the case each stakeholder approves, and finance it

The previous section mapped what each stakeholder fears. This one builds the case that answers it. That means four cases in four languages, plus one move that makes all four easier.

Start by scoping the debt. Bring forward only what is slowing the thing the business is betting on right now. A case for cleaning up code that no longer matters will lose, and it should. The debt worth a fight is the debt costing delivery, revenue, or reliability this quarter, and that is the debt every case below is built on.

CFO: Turn the debt into a number, then shrink it with outside money

The CFO already pays for the debt every month and never sees it on a line. Your job is to put it there.

1. Ask each engineer what share of their week disappears into working around known debt. If a thirty-person team loses a fifth of its time, that is six engineers’ worth of salary, well over a million dollars a year at a fully loaded cost, buying nothing but the debt. That figure is the interest payment the company is already making without knowing it.

2. Then price the risk. Tie the debt to the outages it can cause and cost each one out: revenue lost during downtime, SLA credits owed to customers, and the support hours spent cleaning up afterward. A rough expected value, the chance of a debt-linked incident multiplied by what one costs, is enough to make the exposure real on a slide.

3. Now the ask writes itself. Here is what we already spend every year to keep the debt alive. Here is the one-time cost to stop spending it. Here is the payback period. That is a capital decision a CFO can make, and it is a different conversation from asking for engineering time.

4. Then shrink the one-time cost with money that is not yours. On Google Cloud, the Rapid Migration and Modernization Program (RaMP) funds migration and modernization work through two mechanisms, current as of July 2026 (Google Cloud, 2026):

   • Service funds: A baseline of 20% of a workload’s projected annual recurring revenue (ARR), capped at $2M per workload, used to offset the cost of engaging a partner or Google Professional Services.

   • Quarterly cash-back credits: Google Cloud service credits issued each quarter, tied to the incremental growth of the migrated workloads.

Strategic workloads such as Oracle and SAP can qualify for higher rates, and the program’s assessment phase produces a total cost of ownership and ROI analysis that Google describes as a data-backed business case.

Josef points straight at why the provider does this: there are “synergies found with the hyperscalers where they can help fund addressing these issues,” because a customer who cannot deploy safely is a customer who stops growing. The CFO’s objection was cost. Part of the cost now sits with the provider, and the sticker the CFO was weighing is not the real number.

CRO: Attach the fix to revenue that is already at risk

The revenue leader does not care about architecture. They care about the number they have to hit, so hand them the debt in that number.

1. Pull the accounts that have raised reliability or performance complaints, add up the ARR they represent, and line it up against their renewal dates. That is the revenue the debt is putting at risk, named and dated, and it becomes the CRO’s problem the moment you show it to them.
2. Do the same on the way in. Ask the sales engineers which deals stalled or died in a bake-off because the product was slow, buckled under load, or could not clear a security review. That is the pipeline the debt is costing, and the CRO has been absorbing the loss without a cause to point at.

The value of winning the CRO is that they carry the case for you. When the revenue leader walks in saying the fix protects a specific amount of renewing ARR and opens a specific set of deals, the CFO and the board hear it in a register no engineering argument reaches.

CPO: Bring a delivery plan, not a freeze

The product leader resists because they hear a stop. Take the stop away. Do not ask for a whole quarter to rebuild and pause everything else. Bring a plan that repairs the foundation while features keep shipping, and the objection loses its basis.

Josef frames it as the actual goal:

What you want to be able to do is not to have to stop developing the product, and to do the repair in a way that you can keep shipping new features.

The techniques that make this real are ordinary and worth naming in the room:

• Feature flags: ship changes to the foundation and keep them hidden until they are ready.
• Percentage-based traffic rollouts: send a small share of live traffic to the new version to test it under real load without risking the whole system.
• Controlled production releases: when full pre-production replicas cost too much to run, roll changes into production in small steps instead of freezing delivery to rebuild in the dark.

Then make the cost predictable. Instead of an open-ended project, agree a fixed share of every sprint that goes to the foundation, week in and week out. The CPO trades a frightening pause for a known, bounded tax on velocity, and a bounded cost is one they can plan a roadmap around.

Board: tie it to enterprise value on the exit timeline

The board is not evaluating a repair. They are evaluating what the company is worth when they sell it, so the case has to speak to that.

1. Show how the fix protects or raises enterprise value: reliability that holds retention, performance that wins the enterprise deals that lift ARR, a platform that survives a buyer’s technical due diligence instead of turning into a discount in the negotiation.
2. Then hand them a funded, quantified proposal rather than a request. The same TCO and ROI analysis from the RaMP assessment is the artifact the board wants, now reframed around value at sale instead of engineering health, and it arrives with part of the cost already covered. 

3. Fit it to the window that matters, ahead of the exit the investors are planning for, and the board has a reason to approve that lives entirely in their language.

When each case is built in its owner’s terms, and part of the bill is external, the request that used to stall has four people who can each say yes for their own reason. That is the distance between knowing you have debt and getting the room to let you fix it.

Bring the case to an Architecture Clinic at Revolgy

If you can see the debt clearly and still cannot get the room to agree on fixing it, the case is what needs work. That is what an Architecture Clinic is built to sharpen.

Revolgy’s architects have built these cases across scaling companies, and they have watched which framings the board backs and which ones stall. In an Architecture Clinic, you get that judgment applied to your situation:

• Framing the remediation case for the specific people who have to approve it, in each one’s terms.
• Planning a fix that hardens the foundation while your roadmap keeps shipping.
• Checking whether your workloads qualify for Google Cloud migration funding that offsets the cost.

The Clinic is a free 45-minute 1:1 with a senior Revolgy Google Cloud architect. You bring a real, active problem and the architecture context around it. Within 24 hours, you get a structured summary of the gaps and the next steps. Six slots run each week across two architects. Bring the stakeholder you cannot get to yes, and the workload behind the argument, and book the session.

Book a free cloud expert session

Book a free 45-minute Architecture Clinic with a Revolgy Google Cloud expert now. Only 6 slots run per week.

Claim yours now

FAQs

How do you explain technical debt to non-technical executives?

You explain it in the language of the specific executive in front of you, not in engineering terms. A CFO responds to quantified financial risk, a CRO to churn and the sales team’s ability to keep selling, and a CPO to a plan that protects the feature roadmap. The common failure is presenting one generic technical debt case to all of them at once, which forces each to translate it themselves and usually ends in no decision.

How much technical debt is acceptable?

Some technical debt is expected, and a codebase with none usually signals over-investment. McKinsey’s guidance is that it rarely makes sense to drive technical debt below roughly 10%, because some of it is never worth paying down (McKinsey, 2023). The goal is to fix the debt that is actively slowing delivery or creating risk, not to reach zero.

Who needs to approve fixing technical debt?

Remediation of any real size needs sign-off from the CFO, the CRO, the CPO, and, for larger investments, the board. Each holds a different objection: cost and financial risk, customer and revenue impact, roadmap disruption, and capital allocation against the investment horizon. The CPO is often the hardest to win, because pausing features runs against the metrics they are measured on.

Can you fix technical debt without stopping feature development?

In most cases, yes, by remediating incrementally while shipping continues instead of freezing the roadmap for a full rebuild. Feature flags and small-percentage traffic rollouts let teams change the foundation without a delivery blackout. A plan that keeps features shipping is also far easier to get approved, because it removes the objection the product and revenue leaders care about most.

Does Google Cloud help fund migration and modernization?

Yes. Google Cloud’s Rapid Migration and Modernization Program (RaMP) funds both the migration itself and the business case that justifies it, through partner and Professional Services funding plus service credits tied to workload growth (Google Cloud, 2026). Its assessment phase delivers a total cost of ownership and ROI analysis. A Google Cloud partner can check eligibility and structure the funding.