How to talk to your manager about technical debt (Without sounding like a whiner)
As developers, we all know the feeling. You open a project, and there it is: a mess of hastily written code, patch after patch, and a database held together with virtual duct tape. That's technical debt. The problem? To your manager or client, this "invisible" code works. So why would they pay to rewrite it?
To get time for refactoring, you need to stop talking about technical details. A manager doesn't need to know the details of your architecture. What matters to them is deadlines, costs, and risks. Here's a guide to turning your frustrations into numbers and financial arguments.
Talk about "Delivery speed" (Time-to-Market)
A non-technical team may not see the "ugliness" of the code, but they understand slowness very well. I've lost count of the number of times a project manager has come to me because a deadline was approaching and development wasn't moving fast enough. As technical debt builds up, every new feature takes longer to deliver, sometimes much longer.
- The business argument: "Today, 40% of our development time isn't spent creating new features, but resolving conflicts and bugs caused by our existing code."
- The number to give: Show how delivery times have changed. If a similar task took 2 days 3 years ago and takes 5 days today, you have your evidence. Paying down the debt means speeding up future deliveries.
Calculate the real cost of bugs (The ROI of refactoring)
Technical debt is a real bug factory. And a bug discovered in production almost always costs much more to fix than one found during development or testing. The earlier a problem is identified, the less time and effort it takes to fix. Not to mention that a production incident also damages the trust and image you have with the client.
- The business argument: "Last quarter, outages and bugs caused X hours of service interruption, affecting X clients and potentially slowing down our sales."
- The number to give: Take the team's average hourly cost and multiply it by the time spent firefighting (dealing with urgent issues). If the team spends 10 hours a week on critical fixes, that's thousands of euros wasted every month.
Talk about the risk of turnover (Losing developers)
Working on outdated and frustrating code can quickly become very demotivating. I've already experienced a period when technical debt had become catastrophic: I spent three quarters of my time fixing bugs, while regularly having to deal with criticism from clients. Not exactly the most motivating situation... And when things continue like that over time, there's also a risk of losing developers. And replacing a developer is expensive, very expensive.
- The business argument: "If we continue to ignore code quality, the team will burn out. Replacing a developer who leaves because of technical frustration can take 3 to 6 months and cost tens of thousands of dollars in onboarding."
The "Receipt" method for negotiating
Never ask: "Can we stop for a quarter and rewrite everything?" The answer will always be no. Instead, use the tax strategy: the 80/20 rule.
Propose allocating 20% of each sprint (or budget) to paying down technical debt. Present it as an insurance policy: you continue delivering 80% of the features, while making sure the system doesn't fall apart. By speaking their language (costs, risks, and productivity gains), you'll go from being seen as a "whining developer" to a partner. And that changes everything.
Conclusion
There you go, you've managed to get some time to reduce technical debt. But that was only the first step. The hardest part is often refactoring while continuing to deliver new features. The goal isn't to have perfect code, but to have a project that remains easy to evolve over the long term.
