How do you build a business case for technical debt?

What's really being asked

This question assesses your ability to move beyond complaining about code quality and build a data-driven business case. It tests if you can connect engineering metrics (like cycle time) to business outcomes (like time-to-market and risk) and influence prioritization by speaking the language of product and business stakeholders, not just engineers.

The full answer

First, make the debt visible and quantifiable. Treat debt like a feature or bug by creating specific items in the backlog. Quantify the impact: "Adding this feature took 3 weeks; without this debt, it would have taken 1 week. The 'interest payment' was 2 weeks of developer time, costing the business $20,000 in salary alone." Second, frame it in business terms. Use phrases like "cost of delay," "increased risk of production incidents," or "reduced delivery velocity." Instead of "bad code," say "This debt is slowing our feature velocity by 30% and increases the risk of a P1 outage by 15% each release." Third, distinguish debt from defects. Clarify that this isn't about broken functionality (defects), but about suboptimal code that works but impedes future development. Defects demand immediate attention; debt can be managed strategically. Finally, propose a concrete, incremental plan. Suggest allocating a fixed percentage of capacity, like 15-20%, in each sprint or Program Increment to address the highest-impact items. This shows you understand the need to balance current and future delivery.

The mistakes people make

One major red flag is the "sky is falling" approach, demanding an immediate halt to all feature work for a massive refactoring project without a phased plan. This ignores business reality. Another is bringing vague complaints about "messy code" without specific data on how it impacts velocity, cost, or risk. Candidates also fail when they confuse technical debt with defects, which require different handling, or when they focus on blaming others for the debt rather than presenting a forward-looking solution.

What usually comes next

Expect questions like, "How would you decide which piece of tech debt to tackle first?" Your answer should involve a prioritization framework like WSJF (Weighted Shortest Job First), focusing on debt with the highest negative impact on current development. Another follow-up could be, "What if your manager says no, we can't afford 20% capacity right now?" A good response is to negotiate a smaller allocation (e.g., 10%) for the highest-risk items and make the trade-off explicit: "Okay, we can proceed, but we must accept that Project X will likely be delayed by an additional 4 weeks due to this known issue."

A concrete example

"Our goal is to launch three new payment providers this quarter. However, the existing payment module is tightly coupled to the old UI, a piece of intentional debt from a past deadline. My estimate shows that adding each new provider will take 3 sprints due to this coupling. I propose we allocate 20% of our capacity for the next 2 sprints to build a proper payment service interface first. This investment of ~4 developer-weeks now will reduce the integration time for each new provider to 1 sprint, saving us at least 5-6 sprints of work this quarter and de-risking future payment-related projects."