Advocating for Technical Debt Reduction

I advocate for paying down debt by quantifying its carrying cost in terms leadership already cares about — not "the code is messy" but "this is why features take three weeks instead of three days and why we have a production incident every month." My rule is to build the evidence pack before asking for time, because an engineer complaining about code quality sounds like preference, but an engineer showing PagerDuty incident counts and cycle-time data sounds like a business case nobody can dismiss.

Our monolith had grown for years with no deliberate module boundaries; onboarding stretched to nearly a month and incidents clustered around accidental cross-module side effects. I collected interviews with recent hires, six months of incident stats, and feature lead-time measurements, then proposed a Strangler Fig extraction of the worst-offending subsystem behind feature flags rather than a risky big-bang rewrite. I negotiated a steady twenty percent of sprint capacity instead of an all-or-nothing roadmap halt, which made the plan politically survivable with product partners.

After one quarter the incident volume and feature lead time in that area improved sharply enough that the approach became our default playbook for the next two subsystem extractions. The tip I always give: maintain a lightweight debt register with carrying costs attached to each item so you never have to build a persuasion deck from scratch when the political window opens. Evidence should be ready before opportunity arrives.