Start with the repeated cost, not the untidy code
“This service needs a refactor” describes an activity. It does not identify the problem. Begin with something the team can observe: a pricing change touches four separate implementations, a release needs a manual reconciliation, or a routine failure takes too long to diagnose. Name one example instead of presenting an inventory of everything you dislike.
Then explain the connection. If four implementations must change together, the cost is not simply that the code is duplicated. The team spends time checking consistency, changes become harder to review, and a missed update can affect a customer. Keep these as supported observations or explicit risks. Do not invent a revenue loss to make the argument persuasive.
Make the trade-off visible
Technical work competes with other useful work. Acknowledge what will wait if the team accepts your proposal. “Two weeks now will save us months later” is not a credible guarantee without evidence. A stronger request defines a limited intervention, names what it will displace, and explains what you expect to learn.
Separate essential risk reduction from optional cleanup. A critical recovery path and a naming inconsistency are different problems, even if both appear on a debt backlog. When you group them together, the weaker items can distract from the important decision.
Use evidence the audience can inspect
A small, concrete observation is often more useful than a large speculative number. Bring two recent changes that repeated the same manual work, or one incident in which the design made recovery difficult. Explain what the evidence does and does not show.
If the cost has not been measured, say so and propose a short investigation. You can ask for permission to instrument a workflow before asking for permission to replace it. That makes uncertainty part of the decision rather than something hidden inside your estimate.
Close with a bounded ask
Give the work an end condition. Replacing every old abstraction is open-ended; consolidating the pricing rules for one product area and checking the next change against a baseline is bounded. Name the owner, the review point, and the result that would justify continuing.
When time is short, keep one debt example, one consequence, and one request. Implementation detail can follow if the PM asks how the change works. Conciseness means preserving the decision, not stripping out the trade-off.
Keep the decision in the explanation.
- Observable problem: what keeps costing time or creating risk?
- Product consequence: who is affected and how?
- Bounded intervention: what changes, and what does not?
- Trade-off: which other work will wait?
- Checkpoint: how will we judge the result?
Same situation. Clearer explanation.
The order service is a mess. We need two weeks to refactor the dependency injection and clean up the abstractions before adding anything else.
Every pricing change currently needs the same rule updated in four places. That adds review work and creates a risk of inconsistent prices. I recommend spending two weeks consolidating rules for our main checkout path, which would move the reporting feature back. We can judge the change on the next pricing update: how many places we touch and whether the checks catch inconsistent behavior.
Illustrative examples. Adapt the facts and commitments to your situation.
Common mistakes to catch
- Treating all old code as urgent debt.
- Claiming a payback period you have not measured.
- Asking for a rewrite when a bounded experiment would answer the question.
- Omitting the feature work your proposal would postpone.
Now try saying it out loud.
Use the framework for one attempt. Listen back, choose one improvement, and try again.
Practice this conversationA couple of useful questions
Should I avoid the phrase technical debt?
You can use it after explaining the concrete problem. The phrase is a useful shorthand when both people already share the context; it is a weak substitute for that context.
What if the PM still chooses the feature?
Confirm that the trade-off is understood, record the decision and the condition that should trigger a review, then support the agreed plan. Explaining a risk clearly does not guarantee your preferred priority.