When an engineering team says "we have tech debt," CEOs usually file it under "things engineers say." Tech debt sounds technical — and the way engineers usually frame it (legacy code, outdated frameworks, dependencies that need updating) sounds like an aesthetic problem. Why would the board care?
The actual cost of tech debt is not technical. It's slow product velocity, painful hires, increased risk of incidents, customers who churn after running into bugs, and a CFO who can't predict next quarter's engineering output because every estimate has a fudge factor for "existing system weirdness." Those are all board-level metrics. The translation problem — between what engineering knows and what the board can act on — is usually where the conversation breaks.
The reframe: don't ask the board to invest in tech debt
"Pay down tech debt" is the wrong ask. The board hears "engineering wants to spend customer-facing time on engineering-internal cleanup." That's a hard sell, and it usually loses to whatever the latest revenue initiative is.
Frame the same investment in business outcomes:
- Unlocking velocity. "This system is now adding three weeks to every meaningful feature. The investment we're proposing brings that down to one. Over the next year, that's the equivalent of half an engineering team in throughput."
- Reducing risk. "This component handles X% of revenue and has had Y outages in the last six months. The investment reduces our chance of a Sev-1 incident by Z%."
- Enabling specific roadmap items. "The board approved feature X. Feature X cannot be built on the current architecture. The investment we're proposing makes feature X possible."
Same work, completely different conversation. Boards fund velocity, risk reduction, and roadmap enablement. They don't fund cleanup.
The numbers that work
Engineering teams often resist quantifying tech debt because the numbers feel imprecise. Imprecise is fine. Wrong direction is not.
The numbers that move the conversation:
- Slowdown cost per quarter. "This debt is costing us approximately X engineer-weeks per quarter in slowdowns, retries, and workarounds. At our loaded engineer cost, that's about $Y."
- Incident risk. "This area has had Z incidents in the last six months. Two of them caused customer-facing downtime. The pattern suggests another one in the next 90 days unless we invest."
- Revenue at risk. "Customers on this code path account for $X in ARR. Unaddressed, the next major outage in this area is likely to cost us at least one of them."
- Hiring cost. "Two of our last four engineering candidates declined offers citing concerns about the codebase. Recruiter feedback supports it. This is now affecting our ability to hire above a certain seniority level."
Engineers don't naturally produce these numbers. Part of the CTO/fractional-CTO job is producing them — talking to engineers, putting numbers on the soft data, and translating it for the room that has the budget.
Why the CFO matters more than the CTO here
The CFO controls the budget. They will fund tech-debt work if it's framed as risk reduction or revenue enablement — not if it's framed as engineering cleanliness. Once the CFO is on board, the rest of the conversation gets easier. The CFO is also the most likely person in the room to push back on "we just need to ship faster" with "yes, and we'll ship faster if we do this work first."
The discipline: make it ongoing, not a cleanup quarter
Tech-debt work should be 15–25% of engineering time on an ongoing basis. Not a one-time cleanup quarter. The cleanup-quarter approach is a sign you've been ignoring it for too long, and it usually fails — partly because the team is starved for new work afterward, and partly because the next batch of debt has already started accumulating during the cleanup.
Build it into the operating model. Every roadmap initiative includes its share of debt-paydown work. The team treats it as a normal cost of operation, not a special project.
Your job, not your CTO's
As CEO, your job isn't to know the technical details of your tech debt. Your job is to make sure your CTO is being heard, the cost is being measured, and the budget reflects reality. If your engineering leader is telling you about debt and the budget doesn't change, you have a board-level problem you haven't yet surfaced as one.
If you'd like help having this conversation — translating engineering reality into business priorities the board will fund — we should talk.