How to Convince Your PM to Pay Down Tech Debt

How "can we get some refactoring time?" usually ends

Say this to a PM and 99% of the time you'll hear: "The schedule's too tight right now." And they're not wrong. When has the schedule ever not been tight?

I got rejected 5 times. Every time, I said things like "the code is messy, I want to clean it up" or "tech debt will cause big problems later." But from a non-developer's perspective, these arguments don't land.

Messy code is only a problem developers feel, and "it'll cause big problems later" is a prophecy that doesn't impact this quarter's revenue.

Persuasion approaches that failed

"Code quality is important" -- PM's response: "Sure, but three features get cut from this sprint."

"Other companies set aside time for refactoring too" -- PM's response: "Other companies' situations are different from ours."

"Keep this up and developers will start leaving" -- PM's response: A momentary look of concern, followed by zero schedule changes.

(After the fifth rejection, I started questioning the whole approach.)

What I changed on attempt six

I spoke in numbers. "Currently, modifying anything in the order module takes an average of 3.2 days. Similar-sized changes in other modules take 1 day. After refactoring, the order module could drop to 1.5 days."

Then I connected it to business impact. "There are 4 order-related feature requests scheduled for next quarter. Investing 5 days in refactoring saves 6.8 days next quarter."

For the first time, the PM said "How about we do it in the last week of this sprint?"

What actually happened after refactoring

I spent 5 days refactoring the order module. Honestly, 5 days wasn't enough, so I only covered the basic structural improvements. It wasn't perfect. But modification time dropped from 3.2 days to 2.1 days. Slower than the projected 1.5 days, but still an improvement.

I shared these results with the PM. After that, requesting refactoring time got a little easier. Showing numbers builds trust.

What I learned

Among developers, "the code is messy" is reason enough. But for non-developers, it needs to be translated into cost and time. Not "the code is dirty" but "this code adds 3 extra days to build every feature."

And never ask for a big refactoring all at once. Break it into small chunks, measure each one's impact, and use those results to justify the next round. Build a cycle.

The hardest part, honestly

Even when you get the refactoring time, prioritizing is tough. There are 12 places you want to fix but only 5 days. Start with the highest business impact, they say -- but that judgment is subjective, and I'm never fully confident.

Tech debt is still accumulating, and I've given up the fantasy of ever paying it all off. You just manage it.