How would you frame technical debt for your manager's business case?

WHAT THIS TESTS: Your ability to translate technical constraints into business language that a manager or product owner can act on. Interviewers want to see that you understand technical debt not as a code-quality aesthetic but as a compounding tax on delivery, risk exposure, and optionality. The question specifically probes whether you can connect debt to cost of delay, velocity erosion, and probabilistic risk rather than falling back on engineering intuition.

A GOOD ANSWER COVERS: Four things in order. First, quantification: show the current drag using metrics like sprint velocity decline, increased defect escape rate, or mean time to recovery, and project the compounding cost over the next two to three quarters. Second, business framing: translate that drag into cost of delay by estimating deferred feature value, customer churn risk, or incident remediation costs. Third, remediation options: propose a balanced approach such as allocating twenty percent of every iteration to debt reduction, using WSJF to prioritize debt items alongside features, or scheduling an innovation and planning iteration for concentrated cleanup. Fourth, explicit trade-offs: present two or three roadmap scenarios with different debt paydown rates, each showing projected delivery dates and risk levels so leadership can choose rather than simply approve.

COMMON WRONG ANSWERS: Demanding a full feature freeze until all debt is cleared, which signals an inability to negotiate in a product context. Describing debt with purely technical labels like messy code or outdated libraries without tying them to delivery slowdowns or operational risk. Blaming the business for past decisions rather than treating intentional debt as a strategic choice that now needs refinancing. Offering a single all-or-nothing plan instead of a portfolio of options.

LIKELY FOLLOW-UPS: How would you make debt visible if leadership does not track it today. What percentage of capacity is appropriate for an ART versus a single team. How do you prevent the definition of done from eroding again once you start paying debt down. Whether you would classify this debt as intentional or unintentional and why that distinction changes the communication strategy.

ONE CONCRETE EXAMPLE: Suppose your platform team's velocity has dropped thirty percent over six months due to brittle deployment pipelines and missing test coverage. You calculate that every feature now requires an extra four engineer-days of manual validation, which across twenty features per quarter equals sixteen weeks of lost capacity. You frame the business case by showing that at current burn rates this hidden tax costs roughly two hundred thousand dollars per quarter in delayed releases, and that a targeted six-week remediation reduces the tax by seventy percent. You propose three options: maintain status quo and accept declining throughput, allocate twenty percent of each sprint for three months, or defer two roadmap items to fund an innovation and planning iteration dedicated to pipeline hardening. You recommend the twenty percent option because it preserves most feature flow while stopping the compounding interest.

Source: agility-at-scale.com