Technical debt is an unavoidable reality of software development. Every shortcut, every deadline push adds a bit of debt. Developers feel it, but talking to a manager about it is hard. The “we need time for refactoring” pitch rarely lands.
I’ve had this conversation in different teams for 19 years. Sometimes I got it right, sometimes I got it wrong. Here’s the practical approach I keep coming back to.
The manager’s perspective
Empathy first. When a manager hears “technical debt”, what they actually hear is:
- “The developer wants to refactor”
- “Output will drop”
- “Deadlines will slip”
- “No clear business value”
You can’t make progress until you break that perception.
Use business language
Technical jargon is comfortable for a developer, but it’s noise for a manager. Translate tech debt into business impact:
Developer-speak: “The UserService class is 2000 lines, violates SOLID principles, needs a refactor.”
Manager-speak: “Adding a new feature now takes three weeks instead of one. If we invest some time here, we can ship 5 to 6 features next quarter instead of 2.”
Same problem, different framing.
Measurable metrics
Data, not opinion.
Metrics:
1. Velocity trend. Has team velocity dropped over the last six months? That’s a tech debt signal.
2. Bug rate. Are production bugs increasing in the last three months? Quality is slipping.
3. Deploy frequency. Did you drop from weekly deploys to bi-weekly? That’s risk aversion.
4. Feature time to market. A feature of the same complexity now takes 4 weeks instead of 2?
5. Onboarding time. Did time-to-productive for a new dev go from 1 month to 2?
Record these metrics. Once you have a trend, the manager sees it.
Specific ask
Vague requests get rejected. “We need time for tech debt” goes nowhere.
Specific ask:
“Next quarter, we allocate 15% of velocity to tech debt. Focus: UserService refactor plus test coverage from 40% to 70%. Expected outcome: feature throughput up 30% in Q4.”
Measurable, time-boxed, outcome-focused. A manager can understand and approve it.
Sell with a story
Concrete examples beat abstract arguments.
Abstract: “Code quality is declining.”
Concrete: “Adding ‘Apple Pay’ to checkout last month took 3 sprints. Two years ago, adding ‘Stripe’ took 1 sprint. Same complexity, 6x the time. The codebase can’t carry its weight anymore.”
A story makes the manager empathize.
Refactor vs rebuild
Sometimes a refactor is overkill and a rebuild is needed. The call is tricky.
Pick refactor when:
– Business logic is mostly correct
– Test coverage exists
– The problem is code organization
– Incremental improvement is possible
Pick rebuild when:
– There’s a critical design flaw
– The tech stack is outdated
– There are fundamental security concerns
– Incremental fixes go nowhere
Rebuild is more costly (3 to 6 months). Refactor is ongoing, slice by slice, in parallel with features.
Incremental improvement
Big bang refactors rarely succeed. The incremental approach:
Boy Scout rule: leave the code cleaner than you found it. Small improvements in every PR.
Feature area refactor: when working on a feature, refactor that feature’s code area. The business justification is built in.
Dedicated X% time: each sprint, 15 to 20% goes to technical work. Bug fixes, refactor, small improvements.
These approaches don’t tell the manager “we can’t ship the new feature”. Every sprint delivers both feature work and improvement.
Risk framing
Tech debt risk is tangible for a manager:
Security risk: old framework, known CVEs. Breach risk.
Scaling risk: the system will crumble if users hit 10K. Lost growth opportunity.
Hiring risk: nobody wants to work on this legacy stack. Talent acquisition is hard.
Compliance risk: GDPR, PCI-DSS requirements aren’t met by the old system.
These four risk categories are the alarm triggers for managers.
ROI calculation
Calculate the ROI of the tech debt investment:
Example:
– Tech debt work: 4 sprints (2 months, 2 developers) = 4 person-months
– Expected return: every feature 50% faster, 10 sprints saved by Q4
– ROI: 10 sprints gained / 4 sprints invested = 2.5x
That kind of calculation is the manager’s language. It makes approval easy.
Technical debt register
Every team needs a debt register:
| Item | Impact | Effort | Priority |
|——|——–|——–|———-|
| UserService refactor | High | 2 sprints | 1 |
| Legacy payment module | Med | 1 sprint | 2 |
| Test coverage | High | Ongoing | 1 |
| Old jQuery dependency | Low | 3 sprints | 3 |
Once it’s visible, prioritization gets easier. Review it at every retro.
They said “no”, now what?
Manager won’t give time for refactor. What do you do?
Option 1: comply. Ship the short-term features, let debt pile up. Later, with velocity in critical decline, you have a stronger position.
Option 2: stealth refactor. On every feature, clean up the area you touch. Apply the Boy Scout rule aggressively.
Option 3: document the risks. A formal email: “these are the risks, here are the improvements needed”. If the manager doesn’t approve, responsibility shifts.
Option 4: escalate. If direct manager isn’t enough, skip level. Talk to VP, CTO.
Stealth refactor usually works. Pure compliance usually ends in burnout.
Success story example
How I sold a checkout refactor on one project:
Situation: checkout is 5 years old, three different developers touched it, nobody fully understands it. Every new feature takes 2x longer.
Pitch to manager:
“Over the last six months, velocity on checkout features dropped 40%. Bug rate rose 80%. Users report ‘1.5x slower’ in feedback.
Proposal: 6 weeks of focused refactor. 2 developers. Outcome:
– Velocity recovers 50% (starting mid-Q2)
– Bug rate back to normal
– Test coverage from 40% to 75%
– Onboarding a new dev drops from 3 weeks to 1
ROI: 6 sprints invested, 3 sprints saved per month starting Q3.”
Result: approved. Refactor shipped. The metrics matched the projection.
Wrap-up
A successful tech debt conversation comes from the manager’s perspective, business language, concrete metrics, and a specific ask.
Data, not opinion. Business impact, not effect description. A measurable plan, not a vague request.
With this discipline, most managers come around. If the manager you’re working with never does, the problem is the organization, not the debt.