Introduction
“We need to pay down technical debt” is one of the least persuasive arguments you can make to a product manager or executive. It’s vague, sounds like complaining, and doesn’t connect to business outcomes.
After years of struggling to get buy-in for technical improvements, I’ve developed a framework that reframes technical debt as investment decisions with measurable returns.
The Problem with “Technical Debt”
The term itself is problematic. It implies:
- Something bad that shouldn’t exist
- A burden to be eliminated
- Past mistakes that need fixing
This framing puts engineers on the defensive and makes stakeholders skeptical.
Reframing: Technical Investment
Instead of “paying down debt,” think about “making investments.” Every technical improvement should have:
- A clear cost (engineering time)
- Expected returns (faster development, fewer bugs, reduced incidents)
- A payback period
Quantifying Technical Debt
Developer Velocity Impact
Track how much time developers spend on:
- Working around legacy code
- Debugging issues caused by technical debt
- Onboarding friction due to complexity
Weekly debt tax = (hours spent on workarounds) × (average hourly cost)Incident Correlation
Map production incidents to technical debt items:
- Which systems cause the most incidents?
- What’s the cost per incident (engineering time + business impact)?
- How would addressing the debt reduce incidents?
Feature Delivery Impact
Measure how technical debt affects feature delivery:
- Time to implement features in debt-heavy areas vs clean areas
- Number of bugs introduced in different parts of the codebase
- Developer satisfaction scores by area
The Investment Proposal Framework
When proposing technical improvements, structure it like a business case:
1. Current State Cost
“Our authentication system causes 3 incidents per month, each taking 4 hours to resolve. That’s 12 engineering hours monthly, plus customer impact.”
2. Proposed Investment
“Refactoring the auth system will take 2 sprints (80 hours).“
3. Expected Returns
“Based on similar refactors, we expect to reduce incidents by 70%, saving 8+ hours monthly and improving customer experience.”
4. Payback Period
“The investment pays for itself in 10 months, then continues generating returns.”
Prioritization Matrix
Not all technical debt is equal. Prioritize based on:
| Factor | Weight |
|---|---|
| Incident frequency | High |
| Developer time impact | High |
| Feature velocity impact | Medium |
| Security risk | Critical |
| Scalability risk | Medium |
Communication Strategies
With Product Managers
Focus on velocity and predictability:
- “This refactor will let us ship features 30% faster in this area”
- “We’ll reduce our bug rate, meaning fewer interruptions to planned work”
With Executives
Focus on business outcomes:
- “This reduces our incident rate, improving customer satisfaction”
- “We’ll be able to respond to market changes faster”
- “This addresses a security risk that could result in [specific consequence]“
With Other Engineers
Be direct about the technical benefits:
- “This will make the codebase easier to understand and modify”
- “We’ll have better test coverage and confidence in changes”
Building a Technical Debt Budget
Advocate for a standing allocation:
- 20% rule: Reserve 20% of engineering capacity for technical improvements
- Debt sprints: Dedicate one sprint per quarter to focused debt reduction
- Boy scout rule: Leave code better than you found it (small, continuous improvements)
Tracking Progress
Make technical debt visible:
- Maintain a debt backlog with estimated costs and returns
- Track debt metrics over time
- Celebrate wins when improvements show measurable results
Real Example
We had a legacy notification system that:
- Caused 5 incidents per month
- Required 2 hours of workarounds per feature
- Had no test coverage
Investment: 3 weeks of refactoring Result:
- Incidents dropped to 1 per month
- Feature development time reduced by 40%
- Payback period: 4 months
Conclusion
Technical debt isn’t inherently bad—it’s often a reasonable trade-off. The key is making informed decisions about when to incur debt and when to pay it down.
By framing technical improvements as investments with measurable returns, you can have productive conversations with stakeholders and get buy-in for the work that matters.
Stop asking for permission to “pay down debt.” Start proposing investments with clear returns.