Behavioral Scenario #16
The Invisible Tech Debt
“Your team ships on time. But velocity has dropped 35% over 3 quarters. Your PM thinks it's feature complexity. You know it's debt. How do you prove it?”
The Situation
You're a Staff Android engineer on a team that has shipped consistently on time for 6 quarters. But over the last 3 quarters, average sprint velocity has dropped 35% — the same features take longer, bug counts per release are up, and junior engineers are spending 40% of their time on fixes rather than features. Your PM attributes the slowdown to increasing product complexity. You believe the root cause is accumulated technical debt: 3 years of quick fixes without refactoring. You need to make the case for dedicated debt reduction work without a dedicated 'cleanup sprint.'
Context
- You have no hard data linking specific debt areas to velocity loss — only intuition and anecdotal evidence from retrospectives
- Your PM's OKR includes 5 features in Q3, leaving no slack for explicitly-scoped debt work
- Two engineers on the team have each privately told you that they're considering leaving due to code quality frustration
- The codebase has no automated technical health metrics — no cyclomatic complexity, no test coverage delta tracking
- Engineering leadership has given lip service to 'sustainable pace' but has not funded a dedicated infrastructure quarter
The Question
“Tell me about a time you had to make the business case for technical investment that wasn't directly visible in the product.”
Response Options
One of these is the strongest response. The others reflect common approaches with real trade-offs.
I requested a dedicated 'tech debt quarter' from engineering leadership, citing the velocity drop as evidence that the team needed breathing room.
I instrumented sprint velocity by root-cause category (bug fix vs. debt-related delay vs. feature work), tracked the ratio over 6 weeks to build the data, identified the top 5 debt areas by contribution to delay time, calculated the ROI of addressing each, and presented the PM with 'we can recover 30% of our Q3 feature capacity by addressing these 3 areas — here's which features that unlocks.'
I embedded debt reduction work into each sprint without telling the PM, treating it as overhead that was already included in our estimates.
I raised the retention risk: told my manager that two engineers were considering leaving due to code quality, and framed the debt investment as a retention play.
The Debrief
Why the Best Response Works
Answer B converts a technical argument into a business argument. PMs don't fund 'fixing debt' — they fund 'shipping features.' When you show that addressing 3 debt areas recovers 30% of Q3 feature capacity, you're not asking for maintenance time — you're offering feature acceleration. The 6-week instrumentation is the credibility builder: you're not asking them to trust your intuition, you're showing them your data.
What to Avoid
The 'tech debt quarter' label is the most common failure mode. It signals 'we're going to stop shipping for 13 weeks' — which is never going to get approved. The hidden work approach is worse: when discovered (and it will be), it damages trust in your estimates permanently. The only sustainable path is making the debt visible and the ROI explicit.
What the Interviewer Is Probing
The interviewer is evaluating whether you can speak two languages simultaneously: engineering and product. Staff engineers who can quantify technical debt in feature-velocity terms are significantly more influential than those who argue from technical correctness. This is the skill that gets debt investment funded.
SOAR Structure
**Situation:** 35% velocity drop over 3 quarters; PM attributes to feature complexity; no existing technical health data. **Obstacle:** No hard data; Q3 has 5 features; leadership uncommitted; two engineers considering leaving. **Action:** Instrumented sprint work by category for 6 weeks; identified top 3 debt areas by delay contribution; calculated 30% Q3 capacity recovery from addressing them; presented to PM as 'unlock 2 additional features this quarter.' **Result:** Two debt areas scoped into Q3 sprints; velocity recovered 22% by Q3 end; technical health tracking added to team dashboard.
The Learning Arc
"This taught me that debt arguments fail when they sound like maintenance and succeed when they sound like delivery. The PM was not wrong to prioritize features — features are the business. My job was to show that addressing the debt was the fastest path to the features. Once I made that calculation explicit, the conversation changed from 'tech vs. product' to 'what's the fastest path to the roadmap.'"
IC Level Calibration
Instrument your own work to categorize time spent, build 4–6 weeks of data, identify the top 3 debt areas by time impact, and present the findings to your manager with a concrete proposal.
Build the instrumentation into the team's sprint process, quantify the ROI of the top debt areas, present to the PM with 'this is what we can unlock in Q3 by addressing X,' and get it scoped into sprints as explicit line items — not overhead.
Same as staff, plus: make technical health a first-class engineering metric across the org. Propose a quarterly technical health review as part of the planning cycle. Work with engineering leadership to establish a 20% time allocation for debt reduction as a sustainable pace policy.
Company Calibration
Amazon
LP: Deliver Results — make the data-driven case before the ask
Stripe
Increment: small, measurable improvements compound over time
Engineering excellence: sustainable velocity as a product metric
Bloomberg
Technical rigor + business pragmatism
Want to pick your response and see the full analysis?
Practice This Scenario Interactively