Paying Down Technical Debt Without Stopping the Roadmap

I'm Tom Lang — I've built and scaled engineering organizations for three decades, from startups to 250-plus engineers and through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

When an engineering leader walks into a CEO's office and asks to halt new feature development for a month to "clean up technical debt," they've already lost the argument. To a CEO — especially a non-technical one — "technical debt" sounds like engineers complaining about messy code while the competition ships features. It's a losing framing before you've reached your second sentence.

So here's how I actually handle technical debt: how I make the case, how I decide what's even worth fixing, and how I pay it down without ever asking permission to stop the roadmap.

Making the case: translate the debt

I never use the term "technical debt" with a non-technical founder. I translate it into the only two currencies the business actually cares about: velocity and risk.

The velocity tax — the interest payment. I don't complain that the codebase is ugly. I point at the number: a feature that should have taken three days just took three weeks, because the team had to tiptoe around a fragile, undocumented billing module. Then I frame it as interest: "Every time we touch this module, we pay a two-week interest penalty. If we spend four days refactoring it now, we get those two weeks back on every future release." Now it's an investment with a return, not a chore.

The existential risk. If the debt is infrastructure-related, I tie it directly to a business outcome the CEO can feel: "If we don't decouple this database now, the site physically crashes on Black Friday when we hit 5,000 concurrent users."

Notice what I'm never doing: asking to freeze the roadmap. Instead I'm proving that if we don't fix this specific bottleneck, the roadmap is already frozen — we just haven't admitted it yet.

What's actually worth fixing

The biggest mistake engineers make is assuming all messy code needs to be fixed. It doesn't. If a piece of code is a terrifying, unreadable mess but it runs perfectly in the background and hasn't needed a change in years — leave it alone. Ugliness isn't the enemy; friction and risk are.

I prioritize strictly on two questions: how often do we have to touch it, and how much damage does it cause when it fails?

Debt profile	Frequency of change	Business impact	Action
The friction trap	High — touched weekly	Medium	Fix immediately. Active quicksand — it's slowing daily development and draining morale.
The ticking bomb	Low — rarely touched	Critical — takes the site down	Schedule a dedicated fix. Works today, but fundamentally unscalable (e.g., a single point of failure in the database).
The ugly legacy	Low — runs quietly	Low	Ignore it. It's ugly, but it works. Leave it until the business needs a change there.

And I don't guess at where the friction trap lives — I measure it. I look at the Git history for the five files with the most merge conflicts and churn over the last 90 days, and at Jira for the module that generates the most regression bugs. That intersection is exactly where I aim the cleanup, because that's where the debt is actively taxing the team.

How to fund it without stopping the world

"Stop-the-world" rewrites fail about ninety percent of the time. By the time you finish the six-month rewrite, the business requirements have moved and you're behind the market — you spent half a year to arrive late. So I never do that. Instead I use two continuous funding mechanisms that run invisibly alongside feature work.

The 20% tax — the keep-the-lights-on budget. Every sprint, 80% of capacity goes to new product features and 20% is strictly protected for engineering health. The CEO does not get to raid that 20% when a deadline looms — it's not negotiable, it's the cost of running a professional factory. That protected slice is what continuously upgrades libraries, fixes flaky tests, and refactors the small bottlenecks before they become big ones.

The strangler-fig pattern — the boy-scout rule. When the product team demands a new feature that touches a terrible legacy system, I don't stop to refactor the whole system. We carve off only the piece the feature needs, rebuild that piece cleanly, and route the new feature through it. Over time, as more features arrive, we slowly strangle the old system to death piece by piece — while shipping value every single sprint. (It's the same incremental, wrap-and-replace instinct behind modernizing legacy without a big-bang rewrite and the clean-seams architecture it depends on.)

The honest goal

Here's the whole thing in one line: you don't pay down technical debt by stopping the business. You pay it down by making it a non-negotiable part of the daily engineering process. Translate it into velocity and risk so the CEO says yes, fix only the debt that's actively taxing you, protect a fixed slice of every sprint for it, and strangle the worst systems incrementally instead of rewriting them. Do that and the debt shrinks while the roadmap keeps moving — which is the only version of debt paydown that actually survives contact with a business.

If your team keeps telling you they need to stop and "fix the tech debt," and you're not sure whether they're right or which debt actually matters, that's exactly the kind of call I help leaders make. Book a call and we'll figure out what's worth fixing — and how to pay for it without freezing your roadmap.