It is that time of year again; budget season. You have prepared. You have slides, you have “data”. You have rehearsed your argument. Your time comes. And you make a fundamental mistake:
“We need to allocate this quarter to paying down technical debt.”
The room freezes, and you realize that all your preparation are for naught.
Executives get restless. The VP of Sales looks back to their laptop and starts catching up on emails. The CFO has a look that only means one thing: Not this again.
The problem is both you and it isn’t you. You have been hard pressed to explain WHY you and your team need to spend six weeks “fixing things” that already work. You haven’t been able to elocute why you need to rewrite something that is already written. Your VP of Sales looks up from his laptop and looks at you with disdain, and sees 6 weeks of “no new features moving the business forward.”
You have lost before you even started.
The CFO’s statement is clear and direct, “Denied”.
I hate to say this, but it really IS your fault. You brought a feeling to a numbers meeting. You brought a knife to a gun fight. “Technical debt” only means something to those that actually FEEL it. Those that spend countless lost hours unwinding code just to realize that they are in the wrong module to begin with. You have brought an abstract concept to a balance sheet.
It’s time to stop using terms like “debt”. It’s time to shift the conversation into the financial impact of what technical debt actually is. There are three, concrete, calculable costs that you can leverage during budget season:
1. The Velocity Tax –
Every new feature that requires a fork to dig through the spaghetti takes longer to implement. It would be analogous to asking your VP of Sales to ONLY conduct sales via text messaging. To building a car on a factory floor covered in oil. Everything takes longer. You don’t need to guess at the what’s and the why’s. You have this data sitting in your Git ledger. A forensic analysis of that history can identify these hotspots and show you that any story touching TransactionService.java takes on average 40% longer to complete.
Now you have hard data, your argument is no longer a feeling, it is data. Your presentation shifts to making a financial case:
"Every feature that touches the Transaction Service is taxed at 40%. The next six features on the roadmap all go through it. At our current burn rate, that tax will cost us an extra $150,000 in engineering salaries and three weeks of market delay. A six-week refactor to eliminate that tax has a four-month ROI. It's a bad trade. We need to fix the factory floor."
2. The Blast Radius Tax –
There are parts of your system that aren’t just spaghetti, but they are a mess of DRIED spaghetti. These areas of your system are the load bearing walls that hold everything up. No one is QUITE sure why, but they know if anyone touches the TranactionService.java file, the system is in a world of hurt. Get ready for outages.
Tribal knowledge knows this. YOU know this. The Ops team knows this. What you don’t know is will changing TransactionService.java be the source of failure, or will it be one of the multitude of tightly coupled services?
Again, your Git Log has the answers. Your forensic analysis can show you that every time AuthenticationService.java is changed there is an 80% chance that the Payments, Reporting, and User Profile services will need to change. You may “know” what that blast radius is, but can you prove it?
If you can prove it, you conversation shifts from emotional to factual:
"The AuthenticationService has a change correlation of over 80% with our Payments, Reporting, and User Profile services. The last time a similar component failed, it cost us $500,000 in direct revenue and SLA penalties. We are paying a massive, invisible insurance premium on this component every single day. It's time to pay the deductible and fix it."
3. The Burnout Tax
Your best engineers hate working in the digital sewars of your codebase, of digging through a mess of code. Will they do it? The answer, for the consummate professional, is yes. But will they do it forever? Each time the engineer has to go spelunking, it is a cut to there motivation. This death by a thousand cuts will cause them to leave your organization. And when they do, all their tribal knowledge goes with them. Can you replace them? Absolutely. Can you replace their knowledge? Not quickly.
While this may be partly due to a cultural problem, it really is a churn problem, and it has a real cost.
The conversation needs to leave the emotional, “developer happiness”, argument behind. It needs to be reframed as talent retention:
"The average cost to replace a senior engineer is $150,000 and six months of lost productivity. Our Git forensics show that the last three senior engineers who resigned were the primary and often sole contributors to our top five risk hotspots. We are not losing people to the market; we are systematically burning out our most valuable experts on the most toxic parts of our codebase. This is a self-inflicted wound."
It is time to stop talking about Debt. Start Talking About Money
One of the most challenge parts of being an engineering leader is making the shift from “tech” to “money”. You have to reframe you language into the language of the balance sheet. Stop talking about “technical debt”, start talking about the “velocity tax”, “burnout”, and the “blast radius tax”.
When you do that, you are no longer a whiny engineering manager asking for a favor in a language that is not understood. You are a strategic partner presenting a clear, data-driven, high-ROI investment.
And that is a conversation you will win.
Enjoy your new budget items.