How do you build a business case for technical debt work?

What's really being asked

This question assesses your ability to move beyond a purely technical perspective and act as a business-minded leader. The interviewer wants to see if you can translate 'bad code' into quantifiable business risks and opportunities. They are testing your strategic thinking, your ability to influence product and business stakeholders, and your understanding that engineering resources are a business investment. It's not about complaining; it's about building a compelling, data-driven case for prioritization against competing features.

The full answer

A strong answer connects technical debt directly to business outcomes. First, make the debt visible and understandable. Frame it not as 'refactoring' but as 'reducing the cost of future features' or 'mitigating a reliability risk.' Second, quantify the impact. Use metrics like declining velocity, increased bug rates, or the direct cost of delay for a specific upcoming feature that is blocked or slowed by this debt. Third, propose a concrete, incremental plan. Instead of asking for a 'refactoring sprint,' suggest allocating a fixed capacity, like 15-20% of each sprint, to pay down the debt. Finally, tie the work back to the product roadmap, showing how addressing the debt enables or accelerates future planned features.

The mistakes people make

A major red flag is framing the problem solely in technical terms, like 'the code is messy' or 'we used an old library.' This shows a lack of business acumen. Another mistake is being purely emotional or blaming past teams without providing data. Demanding a full 'stop-the-world' refactoring period without a phased approach is also a sign of immaturity. A candidate who can't explain why the business should care about the debt, beyond making engineers' lives easier, will fail this question. The reference distinguishes between debt (suboptimal but works) and defects (doesn't work); confusing these shows a lack of precision.

What usually comes next

'How would you measure the success of this tech debt initiative?' (Answer: Improved velocity, lower bug count, faster delivery of a specific feature). 'What if your manager says no?' (Answer: Document the risks, propose a smaller scope, and identify a future trigger point where the conversation must be revisited, e.g., 'When feature X becomes impossible, we will need to address this.'). 'How do you prevent this level of debt from accumulating again?' (Answer: Discuss Built-in Quality practices, better Definition of Done, and allocating a permanent, small percentage of capacity for maintenance).

A concrete example

'Our checkout flow has significant design debt from an early MVP. It works, but adding new payment providers, which is on the Q3 roadmap, will take an estimated 6 sprints instead of 2. The cost of delay is $50k per month in lost revenue. I propose we allocate 20% of our capacity for the next 4 sprints to refactor the payment module. This will cost us roughly 0.8 sprints of feature work now but will save us 4 sprints of effort in Q3, unblocking the new revenue stream and reducing our bug rate, which currently costs 10 engineer-hours per week to manage.'