How to Talk About Refactoring Priorities in English

Convincing a product manager or non-technical stakeholder to prioritise refactoring work over new features is a recurring challenge — and doing it well in English requires framing technical concerns in terms of business impact, not just code quality. This guide gives you the vocabulary and phrases to discuss refactoring priorities clearly and persuasively.

Key Vocabulary

Technical debt — the accumulated cost of past shortcuts or outdated design decisions, which slows down future development if left unaddressed. “We’ve been accumulating technical debt in the checkout module for two years — every new feature there now takes twice as long as it should.”

Velocity impact — the effect that code quality, or the lack of it, has on how quickly a team can ship new work. “The velocity impact is measurable — our last three features in this module each took 40% longer than similar features elsewhere in the codebase.”

Risk of regression — the likelihood that a change introduces a new bug, often elevated in poorly structured or untested code. “Every change to this file carries a high risk of regression because there’s no test coverage and the logic is deeply intertwined with three other modules.”

Incremental refactor — a refactoring approach done in small, low-risk steps alongside regular feature work, rather than a large rewrite. “Rather than proposing a full rewrite, I’m suggesting an incremental refactor — we clean up one module every sprint alongside normal feature work.”

Opportunity cost — what a team gives up by choosing to spend time on one thing (or not) instead of another. “The opportunity cost of not refactoring this now is that we’ll spend that same time, plus more, fixing bugs caused by the current design over the next year.”

Investment framing — describing refactoring work in terms of a return over time, similar to a financial investment, to resonate with business stakeholders. “I framed the refactor as an investment: two weeks now, in exchange for an estimated 20% faster delivery on this module going forward.”

Blast radius (of a change) — how much of the system is affected by a change, relevant when arguing that a fragile area needs to be made safer before further changes. “Any change in this module has a large blast radius — a bug here has previously taken down three unrelated features.”

Non-functional requirement — a quality attribute like maintainability, performance, or scalability, as opposed to a specific user-facing feature. “Maintainability is a non-functional requirement just like performance — it doesn’t show up in a demo, but it directly affects how fast we can deliver future features.”

Making the Business Case

• “I’d like to propose we spend two sprints on this refactor. The business case is that our last three features here each slipped their deadline, and this module is the common cause.”
• “This isn’t about code aesthetics — it’s about the fact that every bug fix here currently takes an average of three days, versus half a day elsewhere.”
• “If we don’t address this now, the next feature request in this area will likely take even longer, and the risk of a production incident increases.”

Negotiating Time for Refactoring

• “Could we allocate 20% of this sprint to paying down debt in this module, rather than treating it as an all-or-nothing decision?”
• “I’m not asking for a full rewrite — an incremental approach means we can pause at any point if priorities shift.”
• “What if we tie this refactor directly to the next feature request in this area? We’d refactor the specific path that feature touches, rather than the whole module.”

Responding to Pushback

• “I understand the pressure to ship the new feature first. Can we agree on a smaller, scoped refactor that unblocks just this feature, and revisit the rest later?”
• “I hear the concern about timeline risk. To be clear, the risk of not doing this is that similar features will keep taking longer, which compounds over time.”
• “That’s a fair question — here’s a rough estimate of the cost either way: two weeks of refactoring now, versus an estimated extra week per feature going forward if we don’t.”

Professional Tips

1. Translate code quality into time and risk, not aesthetics. “This will save us an estimated week per feature” resonates far more than “the code is messy.”
2. Propose incremental options alongside a full solution. Giving stakeholders a smaller, lower-risk alternative makes it easier to say yes to something.
3. Tie refactoring to concrete upcoming work when possible. “Let’s refactor the path this next feature touches” is easier to approve than an open-ended cleanup project.

Practice Exercise

1. Write two sentences translating “this code is messy” into a business-impact argument for a product manager.
2. Write a short proposal (4-5 sentences) for an incremental refactor tied to an upcoming feature.
3. Write a response to a stakeholder who pushes back on a refactor request by asking “can’t this wait?”