The tension between shipping features and addressing technical debt is one of the most persistent conflicts in software organisations. Engineers want to refactor and modernise; product managers want to deliver user value. As an engineering manager, you sit at the intersection of these competing priorities. This guide helps you mediate constructively and find sustainable balance.
Understanding the Root of Technical Debt Disputes
Technical debt disputes are rarely about technical debt itself - they are about competing priorities, different incentives, and incomplete information. Engineers experience technical debt daily as friction that slows them down and creates bugs. Product managers do not see the debt directly; they see feature velocity and user metrics. Both perspectives are valid but incomplete.
The language gap makes these disputes worse. When engineers say 'we need to refactor the payment service,' product hears 'we want to spend time on something that does not benefit users.' When product says 'we need to ship this feature by next month,' engineers hear 'we do not care about code quality.' Bridging this language gap is your core responsibility.
Chronic technical debt disputes often signal a broken planning process. If the only way engineers can get time for debt reduction is by arguing with product, the process is failing both sides. Building debt management into the regular planning cycle prevents these conflicts from recurring.
Quantifying Technical Debt in Business Terms
Translate technical debt into terms that product managers and stakeholders understand. Instead of saying 'the codebase is a mess,' say 'every new feature in this module takes 40% longer to build because of the accumulated complexity' or 'we have had three production incidents this quarter directly caused by this legacy code.'
Track the cost of technical debt over time. Measure how much unplanned work is caused by debt, how much longer tasks take in debt-heavy areas versus clean areas, and how many incidents are debt-related. This data transforms the conversation from opinions to evidence.
Prioritise debt based on impact, not aesthetics. Not all technical debt needs to be addressed. Focus on debt that is actively slowing the team, causing incidents, or blocking planned future work. Debt in areas that are rarely modified can often be tolerated indefinitely.
Building the Business Case for Debt Reduction
Frame debt reduction as an investment that enables faster feature delivery, not as a competing priority. Show the projected velocity improvement: 'If we spend two sprints refactoring this service, we estimate a 30% reduction in development time for the next three features in this area.'
Propose a concrete plan with measurable outcomes. Instead of open-ended refactoring, define a specific scope, timeline, and success metrics. Product managers are much more likely to support a well-defined proposal than a vague request for 'tech debt time.'
Finding a Sustainable Balance
Allocate a consistent percentage of team capacity to debt reduction - typically 15-20%. This should be a standing agreement, not something renegotiated every sprint. Making it part of the regular cadence removes the conflict from individual planning sessions.
Integrate debt reduction into feature work wherever possible. When building a new feature in a debt-heavy area, include cleanup as part of the project scope. This approach is more efficient than dedicated refactoring sprints because the team is already working in the relevant code.
Use a shared backlog for technical debt that both engineering and product can see. Prioritise it based on impact and urgency, just like feature work. Transparency about the debt backlog and the plan to address it reduces anxiety on both sides.
Mediating Between Engineers and Product Managers
When a dispute arises, bring both sides together for a structured conversation. Have engineers explain the specific impact of the debt - not in technical terms, but in terms of delivery speed, reliability, and risk. Have product explain the business context and deadlines driving their priorities.
Look for creative compromises. Perhaps the debt can be addressed incrementally alongside feature work. Perhaps the most critical piece can be fixed now while the rest is scheduled for a quieter period. Perhaps the feature can be designed to avoid the debt-heavy area entirely.
If you cannot reach agreement, make the decision yourself and explain your reasoning. As the engineering manager, you have the authority and responsibility to allocate engineering time. Make the call, communicate it clearly to both sides, and commit to revisiting the balance if the results do not support your decision.
Key Takeaways
- Bridge the language gap by translating technical debt into business impact - velocity, incidents, and risk
- Quantify debt with data on unplanned work, development time overhead, and incident frequency
- Frame debt reduction as an investment in faster delivery, not a competing priority
- Allocate a consistent percentage of capacity to debt reduction as a standing agreement
- Mediate disputes by bringing both sides together, seeking creative compromises, and making clear decisions
Frequently Asked Questions
- How much time should my team spend on technical debt?
- A common guideline is 15-20% of team capacity, but the right amount depends on your context. Teams with severe debt that is causing frequent incidents may need more; teams with a relatively clean codebase may need less. The key is consistency - a regular, predictable allocation is more effective than sporadic large investments. Track the ratio of planned to unplanned work as a health indicator.
- What if my product manager refuses to allocate any time for technical debt?
- Escalate with data. Show the cost of inaction: declining velocity, increasing incident frequency, growing maintenance burden. If the product manager still refuses, involve your mutual leadership. This is a strategic disagreement that should be resolved at a level where both engineering quality and business delivery are weighed. In the meantime, use the capacity you directly control to make tactical debt reductions.
- How do I prevent technical debt from accumulating in the first place?
- Build quality practices into your development process: meaningful code reviews, automated testing, architecture decision records, and explicit quality standards. Allow adequate time for design and implementation rather than rushing to meet aggressive deadlines. When you do take on deliberate technical debt, document it and schedule the repayment explicitly. Prevention is far cheaper than remediation.
Get Technical Debt Management Templates
Download our technical debt tracking templates, business case frameworks, and capacity allocation models for engineering teams.
Learn More