Every engineering team I've worked with has had "the debt conversation" at some point. Usually it goes something like: "We need to stop feature work and pay down technical debt."
This framing is unhelpful. It creates a false dichotomy between progress and quality. The reality is more nuanced.
What Technical Debt Really Is
Ward Cunningham's original debt metaphor was about shipping code that worked but wasn't well-factored—a conscious trade-off for speed. Over time, the term has expanded to cover everything from outdated libraries to poorly written code.
I find it useful to distinguish between:
Deliberate debt: Conscious decisions to ship imperfect code faster. These should be documented and have a repayment plan.
Accidental debt: Consequences of decisions that seemed reasonable at the time but didn't age well. Often only visible in hindsight.
Bit rot: Code that was fine when written but has become problematic as the codebase evolved around it.
A Framework for Prioritization
Not all debt is equal. We use a simple matrix to prioritize:
Impact × Effort
High impact, low effort: Do these first. Quick wins that make a real difference.
High impact, high effort: Plan these carefully. Break into smaller pieces if possible.
Low impact, low effort: Handle opportunistically. Fix when you're in the area anyway.
Low impact, high effort: Consider not doing these at all. The opportunity cost is too high.
Making Debt Visible
The biggest challenge with technical debt is that it's invisible to non-engineers. Business stakeholders see features shipped; they don't see the growing maintenance burden.
We've found success with:
-
Tracking time spent on debt-related work: Show the real cost of not addressing it.
-
Connecting debt to business impact: "This legacy system requires 20 hours/month to maintain, limiting feature capacity."
-
Including debt reduction in roadmaps: Make it part of normal planning, not a special initiative.
The 20% Rule
We allocate roughly 20% of engineering capacity to debt reduction and infrastructure improvement. This isn't a tax on productivity—it's an investment in future velocity.
This number isn't sacred. Some quarters it's 15%, some it's 25%. The key is consistency: some capacity is always reserved for improvement.
Conclusion
Technical debt isn't a problem to solve—it's a force to manage. Like financial debt, it can be a useful tool when used strategically, and a crushing burden when ignored.
The goal isn't zero debt. It's having the debt you've chosen to carry, not the debt that accumulated through neglect.