Direct answer. Technical debt is choosing a faster, less durable way to build something now, with the understanding that it will cost more time later to fix properly -- like taking on a loan: useful when deliberate and tracked, costly when it accumulates unnoticed and unpaid.
Measurable indicators, not just a feeling
- Rework rate: the percentage of engineering time spent fixing/adjusting existing features versus building new ones -- a rising trend is a concrete signal debt is compounding, even if nobody can point to a specific 'debt item.'
- Time-to-ship a comparable feature, over time: if similar-sized features are taking measurably longer to build than they did a year ago, that's debt manifesting as friction, trackable via delivery data rather than opinion.
- Incident rate tied to a specific area: if one part of the system accounts for a disproportionate share of production incidents relative to its size, that's a concrete, defensible signal of where debt is actively costing the business, not just where code 'looks messy.'
Why concrete indicators matter more than a vague appeal
A non-technical stakeholder can't evaluate 'this code is ugly' as a basis for prioritizing engineering time, but they CAN evaluate 'feature delivery in this area has slowed 40% over two quarters, and it accounts for 25% of our incidents despite being 10% of the codebase' -- the same underlying reality, translated into terms that connect to business outcomes they already track.
Framing it as a trade-off, not a moral failing
Debt isn't inherently bad -- shipping fast with a known shortcut, TRACKED and communicated, is often the right call under real deadline pressure. The problem is UNTRACKED debt (nobody decided to take it on, it just accumulated) or debt that's never revisited despite compounding cost. Framing it this way (a deliberate, trackable trade-off) tends to land better with stakeholders than framing it as 'the code is bad,' which reads as a complaint rather than a decision point.
Trade-offs and pitfalls
- Avoid using 'technical debt' as a catch-all excuse for any code a stakeholder doesn't like the shape of -- reserve the term (and the indicators) for genuine, measurable friction, or the concept loses credibility with stakeholders the first time it's invoked for something that turns out not to matter.
- Indicators can be gamed or misread (a spike in rework could reflect a genuinely hard new requirement, not accumulated debt) -- pair quantitative signals with a concrete qualitative example stakeholders can understand, so the number isn't the whole argument.
