Every engineering team has a backlog item that keeps getting bumped. It sits three sprints out, permanently. Someone mentions it in retro, someone else nods, and then a customer escalation lands and the conversation moves on.
That item is usually a refactor. And the reason it never gets prioritized is that the team pitches it wrong.
"We need to clean this up" is not a business case. "This code is embarrassing" is not a business case. Even "we're accumulating tech debt" is, at best, a slow-moving weather report. Leadership hears it, files it under "things engineers care about," and returns to the revenue conversation.
The refactors that actually get done — and pay for themselves fast — start from a different question entirely.
The useful question isn't "what's messy?" It's "what can't we do right now that a paying customer needs?"
When you frame a refactor around the constraint closest to revenue, the conversation changes. You stop arguing about code quality and start arguing about pipeline velocity, support cost, or time-to-close.
A few patterns show up repeatedly:
Onboarding friction. A new customer signs. Getting them live takes two weeks of back-and-forth because the setup path demands manual steps — the original design assumed a single configuration. Refactoring to support multiple configurations without hand-holding turns a two-week onboarding into a two-day one. That's not a code quality win. That's a capacity win: the team onboards more customers per quarter without adding headcount.
Support ticket gravity. One area of the product generates 40% of support volume. The root cause isn't a bug; it's a data model that forces users into a confusing workaround. Fix the model, eliminate the workaround, eliminate the tickets, free support to handle conversations that actually need a human.
The impossible feature. A prospect asks, "Can you do X?" Sales says, "Not yet." Engineering says, "Not with the current architecture — that would take months." But the blocker is one tangled dependency, not the entire system. Removing that dependency is a two-week job. The feature that was "months away" ships in three weeks. The deal closes.
In each case, the refactor isn't justified by cleanliness. It's justified by a number someone in the business already cares about.
The trap with refactor work is scope creep dressed up as thoroughness. You set out to fix one constraint and someone says, "While we're in there, we should also…" and suddenly a two-week project is a quarter-long rewrite.
Good refactor discipline looks like surgery, not renovation. Define the constraint. Identify the smallest change that removes it. Ship that change. Measure whether the constraint is actually gone.
If it is, celebrate and move on. If the next constraint is nearby in the code, that's a separate conversation with a separate justification. Chaining refactors into a single mega-project is how you end up with the six-month rewrite that delivers nothing until month seven — if it delivers at all.
Engineers describe refactors in terms of what changes inside the system. Leaders want to know what changes outside the system. Bridging that gap is the whole game.
A useful template: "Right now, [business process] takes [current cost in time/money/people]. The bottleneck is [specific constraint]. If we remove it — estimated at [duration] of engineering time — [business process] improves to [target metric]. Here's how we'll verify."
That's a pitch with a falsifiable claim. If the metric doesn't move, the team learns something. If it does, the refactor paid for itself and everyone has evidence that this kind of work deserves future prioritization.
The first refactor that visibly moves a business metric does something more valuable than the metric itself: it builds organizational trust in engineering judgment. The next time someone proposes focused technical work tied to a clear outcome, the conversation is shorter. Approval is faster. The team earns autonomy to maintain the system proactively instead of reactively.
That trust is fragile. One sprawling, unjustified rewrite can erase it. Which is why discipline matters more than ambition here. Small, targeted, outcome-linked. Repeat.
Tech debt is a useful metaphor, but the most expensive debt most teams carry isn't in the code. It's in the gap between what the product can do and what the next ten customers need it to do.
A focused refactor closes that gap — not by making the codebase prettier, but by making the business faster. The best version of this work doesn't feel like paying down debt at all. It feels like removing a wall you forgot you'd built.
The refactor that pays for itself in weeks isn't the one that makes engineers proud of the code. It's the one that makes the constraint disappear — and everyone notices because something that used to be hard just isn't anymore.
Be the first to comment.
0 comments
Loading comments...