How do you explain tech debt to a manager or PM?
What is being assessed
Whether you can translate engineering problems into business terms and negotiate rather than complain. "The code is ugly, it needs a rewrite" is not an argument; "the next three features will take twice as long, and here's why" is.
Answer skeleton
- The language of consequences: tech debt = feature speed, bug count, incident risk, onboarding time. No jargon like "retain cycle" — only impact.
- Numbers: how much time the workaround costs now, how much the fix costs, how many bugs came out of this area last quarter.
- Cost of inaction vs cost of fixing — and when the two lines cross.
- A plan that doesn't stop delivery: refactoring in slices inside features, the Boy Scout rule, 10–20% of a sprint, a feature flag for a safe switch.
- Agreed criteria: what counts as "done", how it will be measured.
Example answer
S: A callback-based network layer with hand-written JSON parsing; every new API feature needed 2–3 days of plumbing and produced threading bugs.
T: Convince the PM to allocate time for moving to async/await + Codable with a packed roadmap.
A: I gathered a quarter of data: 6 bugs from the network layer, 11 days spent wiring new endpoints. I came not with "we need a rewrite" but with a proposal: the next three features already touch 70% of the endpoints — we build them on the new layer and remove the old one as we migrate, with no separate "refactoring sprint". I named the risk: the first feature ships two days later.
R: The PM agreed because they saw numbers and a plan that didn't stop delivery. Two months later wiring an endpoint took half a day, and the next quarter had one bug from that area.