Ask a management team about technical debt and you'll almost always get the same answer. The platform is modern and cloud-native, debt is manageable, and the team puts about 20% of capacity toward it every quarter. That answer tells you almost nothing.
A percentage is a planning assumption. It's not a description of the debt. In my experience, that 20% gets raided the first time a customer commitment slips, and nobody has written down what the debt actually is. It shows up instead as symptoms: releases that keep slowing down, defect rates that creep up, a few engineers nobody can afford to lose, and features that take three times longer than they should.
Technical debt isn't a moral failing. Every product that grows fast carries it. The problem is unpriced debt. If it isn't in the model, the value creation plan pays for it anyway, in slower delivery and higher R&D cost per dollar of growth. So I ask for the list. A credible team has a technical debt register: every significant item named, sized in engineering weeks, prioritized, and owned. Here's what I expect to see on it:
Architecture. Monoliths that block independent releases, single-tenant deployments, components that won't scale to the growth plan.
End-of-life dependencies. Frameworks, languages, databases and operating systems past or near end of support.
Customization. Customer-specific branches, forks or configurations that have to be maintained separately.
Test and release. Thin automated test coverage, manual release steps, long regression cycles.
Security and compliance. Open penetration test findings, unpatched vulnerabilities, gaps against SOC 2 or customer requirements.
Data. Duplicated or inconsistent data across products, missing audit trails.
Knowledge concentration. Systems only one or two people understand.
Then I ask for the numbers that don't lie. What share of engineering capacity actually went to debt, maintenance and unplanned work in each of the last four quarters, measured rather than planned? How have deployment frequency, lead time, change failure rate and time to restore service trended over two years? Is a rewrite or re-platform planned, and is it in the model?
And one question that gets the most insightful answers: which parts of the system would your best engineers rewrite if they could, and why haven't they? That's also why I always ask for time alone with two or three senior engineers, without management in the room. Not to catch anyone out. Senior engineers are usually proud of their work and candid about its weak spots. When their description of the system matches the architecture slide, that's a great sign. When it doesn't, you've found where to dig.
For portfolio companies, the most valuable thing you can do before a sale is build the register yourself. Name it, size it, prioritize it against the growth plan, and show a funded plan for the items that block the roadmap. A buyer who sees a sized, owned list will treat debt as a known cost. A buyer who hears a percentage will commission their own assessment, and they'll find more than you'd like.
AI makes this more urgent. Every AI feature ships on top of the existing platform. Debt slows every AI release and raises the risk of each one.
The red flag: no register, a percentage in place of a list, and senior engineers describing a different system than the slide. Commission an independent technical assessment before signing, and fund remediation from day one.
Next week: Billing and Rating.
