Technical debt conversations fail in two directions. Engineers describe it in jargon and moral panic, so the board hears noise. Or founders hide it entirely, so the board hears nothing — until it surfaces as a missed quarter, an outage, or an ugly surprise in due diligence.
Here's the translation layer.
What technical debt actually is
Drop the metaphors about rot and rust. Technical debt is borrowing speed from the future: choices that made last quarter faster and make next quarter slower. Like real debt, it's a tool. Startups should carry some — a pristine codebase at a company with no customers means someone optimized the wrong thing. The question is never "do we have debt," it's "do we know what we owe and what the payments are."
The only framing your board needs
Three sentences, quarterly:
- "Here's where debt is slowing us down today" — named areas, in product terms: "checkout changes take three weeks instead of three days."
- "Here's what we're deliberately not fixing, and why" — proves it's a managed portfolio, not denial.
- "Here's the interest rate trend" — is the drag getting better, worse, or holding steady?
That's it. Boards manage portfolios of risk all day; give them debt as a risk line-item, not a lecture on software entropy.
The one metric
If you track a single number, track velocity on comparable work: how long a routine, medium-sized feature takes now versus two quarters ago. It's imperfect and gameable, and still ten times better than nothing, because it turns "the engineers seem frustrated" into a trend line. When the trend degrades two quarters running, that's your signal to schedule paydown — before the team starts using the r-word.
Budget it like rent
The teams that stay fast reserve 15–20% of engineering capacity, every sprint, permanently for paydown and maintenance. Not a "debt sprint" twice a year — those are crash diets, and they end the same way. A standing budget removes the recurring fight, keeps paydown incremental, and means nobody has to declare an emergency to fix the thing everyone knows is broken.
If your team is asking for a multi-month feature freeze to "fix the foundation," that's not a paydown plan — that's the velocity trend line having been ignored for two years. (And see the rewrite chapter before agreeing to anything.)
What debt sounds like in due diligence
Investors don't run your test suite. They ask your engineers questions and listen for hedging: "How long to add a payment method?" "What happens if the lead engineer leaves?" "Why is this rewrite in the roadmap?" Managed debt survives those questions fine — unexplained debt is what kills valuations. The board framing above is, not coincidentally, exactly the story that holds up in a data room.
The red flags that mean "act now"
- Engineers can't estimate anything anymore — everything is "it depends what we find"
- The same subsystem causes a second production incident
- Onboarding a new engineer takes months instead of weeks
- The phrase "nobody knows how that part works" said about anything that touches money
Any of these means the interest payments are compounding. That's when a structured assessment — internal or independent — beats another quarter of hoping.