How to Justify a Refactor to a Skeptical Manager in English
Learn how to make the business case for a refactor in English to a manager who sees it as unnecessary work with no visible feature output — without resorting to vague appeals to 'code quality.'
“Code quality” is one of the weakest arguments an engineer can make to a manager who is judged on shipped features, because it’s unfalsifiable and invisible on a roadmap. The English that actually works here translates the refactor into the manager’s own vocabulary — velocity, risk, and cost — with specific numbers wherever possible, rather than asking them to trust an engineering instinct they can’t independently verify.
Key Vocabulary
Velocity tax — the ongoing, recurring cost a piece of messy code imposes on every future change made near it, framed as an interest payment rather than a one-time inconvenience. “Every feature we’ve shipped in this module in the last two quarters has taken roughly 40% longer than similar work elsewhere, because of the velocity tax this tangled state management imposes — that’s not a one-time cost, it compounds with every sprint we don’t address it.”
Blast radius — the scope of code, features, or systems that could be affected if something goes wrong in a given area, used to explain why a small-looking bug fix in this code is riskier than it appears. “The blast radius of any change here is large — this module is imported by six other services, so a bug introduced during a quick fix doesn’t stay contained, it propagates.”
Incremental refactor — a refactor broken into small, independently shippable steps that don’t require a dedicated “refactor sprint” or a feature freeze, which is usually the argument that actually gets approval. “I’m not asking for a two-week feature freeze — this can be an incremental refactor, one module at a time, folded into the existing sprints alongside normal feature work.”
Opportunity cost of inaction — what continuing to build on the current structure will cost in the future, framed as a comparison against the cost of refactoring now, rather than the refactor being evaluated in isolation. “If we don’t refactor this now, the opportunity cost is that the next major feature — which touches this exact code — will take an estimated three extra weeks, which is more than the refactor itself would cost.”
Common Phrases
- “I want to frame this in terms of velocity, not code aesthetics: here’s what this area has cost us in the last two quarters.”
- “This isn’t a request for a dedicated refactor sprint — I’m proposing an incremental approach, folded into normal feature work.”
- “The blast radius here is larger than it looks, because [specific downstream dependency].”
- “If we don’t address this now, the opportunity cost shows up specifically in [upcoming planned feature].”
- “I can scope this to the smallest version that removes the recurring cost, if the full version feels too open-ended to approve.”
Example Sentences
Opening with numbers instead of a general complaint: “Looking at our last six tickets touching the billing module, the average time-to-ship was 2.5x our team average. I think that’s a velocity tax worth addressing, and I want to walk through why.”
Reframing “urgent but invisible” risk into visible terms: “This isn’t about the code looking clean — it’s that the blast radius of any change here includes the payment reconciliation job, and we’ve had two near-misses in the last quarter that didn’t become incidents by luck.”
Proposing a scoped, low-risk path instead of an open-ended ask: “Rather than a big refactor project, I’d like to do this incrementally — starting with the highest-cost piece, which I estimate at three days, and showing you the velocity difference before we commit to more.”
Professional Tips
- Quantify the velocity tax using real ticket history if at all possible — “this feels slow” persuades no one, but “our last five tickets here took 2x longer than comparable ones” is hard to argue with.
- Use blast radius to justify urgency without exaggerating it — naming the actual downstream systems affected is more convincing than a general claim that “something could break.”
- Always propose the work as an incremental refactor unless there’s a genuine reason it can’t be — managers say yes to bounded, reversible asks far more often than to open-ended ones.
- Frame the opportunity cost of inaction against a specific upcoming feature on the roadmap, not a hypothetical future — tying it to something the manager already cares about makes the tradeoff concrete.
- Offer to prove the value with the smallest possible slice first — a three-day pilot that visibly speeds up the next ticket builds more trust than any argument, and makes the next ask easier.
Practice Exercise
- Write a sentence quantifying a velocity tax using specific ticket or timeline numbers.
- Describe the blast radius of a hypothetical refactor target, naming at least one concrete downstream dependency.
- Propose an incremental refactor plan in two sentences, scoped to a single first step.