When’s the last time you had a conversation about technical debt that didn’t end with an exasperated sigh?
During my tenure in this field, I’ve seen teams fall apart due to technical debt, and I’ve seen teams rally together to keep the business alive and thriving by paying back the right debt at the right time. It’s never been completely obvious to me as to when it’s a good time to tackle technical debt, and so I started asking questions of the right people, and frighteningly, I started getting the answers I was looking for!
Register for our free Technical Debt Panel on July 24th – 12pm EST!
It’s a sales problem
At the end of the day, the business is simply not interested in spending its time on something that it sees zero value in. Even if your organization is led by a technical co-founder, you’ll be hard-pressed to sell technical debt with an argument of “well, it’s there, so we might as well take care of it.” The key issue here is that the idea of “paying back technical debt” does little to explain to the business what it will get in exchange for the time and resources spent paying it back. Let’s be honest – given enough time, we could think up a million things that could be changed about the code base we’re working in. No business has the resources to tackle an infinite number of things, and so convincing the business to tackle technical debt resolves down to a sales problem.
Of course, being trusted in your organization goes a long way to getting your needs met, regardless of where you stand in the business hierarchy. A great way to build trust is to construct a case for tackling a piece of technical debt in a way that speaks to the financial aspect of the problem, rather than the technical aspect. By giving the budget committee an argument in the language of finance, which can then be backed up by technical data, you’re going above and beyond what most budget requests look like, and you’re more likely to get budget for your project. Even if you’re not the one directly interfacing with the committee, providing this data for the person who is (likely your manager) goes a long way towards establishing trust.
There are two approaches I’d like to mention here, each with its own strengths.
Selling on risk-mitigation
I pay my credit card bill every month, not for the sake of reducing my debt, but because the risk of having bad credit is scary to me. If I could get away scot free, believe me, I would, without hestitation. Similarly, an organization might increase spending on security not because Security is A Good Thing, but because the risk of losing customers and trust in a breach is a scary proposition worth mitigating, if the price is right.
This is how the sales pitch works – in order to sell technical debt to the business, one needs to speak about the cost in terms that the business understands. What’s the true cost of not upgrading to patch the vulnerabilities that your app is currently exposing? It’s not hard to gather some data on the revenue loss experienced by competitors when they were impacted by similar problems and compare them to your own to come up with an estimate.
Let’s say that there’s a 25% chance that a breach happens this year, with an expected drop in revenue of 20% due to loss of customer trust. It will cost $1MM to upgrade systems to a point where they are no longer vulnerable. Is it worth a $1MM spend to mitigate an expected loss of (25% x 20% = 5%) of total revenue this year? By offering a budget committee this type of financial argument, you’re communicating in terms that the business can act on, and this goes a long way towards getting the action you’re looking for.
That said, not all technical debt is as cut-and-dry as security. What about the case where code is simply old, crusty, and a pain to work with? This is where my mind goes when I think of technical debt. There are two ways to make a business case for tackling this type of debt that I’ll mention here.
The first way is to sell the business on the idea that you can reduce recruiting expenses by keeping the code base modern and relatively clean. Great developers tend to gravitate towards great technologies, and this makes hiring easier. Note that I didn’t mention increasing developer happiness; this is something intuitive to the CIO/CTO, but not necessarily intuitive to the budget committee.
Here’s how the argument might go: by spending 10% of our time on tackling code quality issues, we can reduce our recruiting expenses by 30% through increasing developer tenure. We’re currently spending $300K a year on recruiting, and we’ll basically break even by tackling the code quality issue, not to mention the intangible benefit of keeping institutional knowledge from walking out the door. If the budget committee trusts you enough, this should be an easy sell, given the right timing, which I’ll touch on in a moment.
The second way to sell an improvement to crusty code takes us to our next sales strategy:
Selling a growth opportunity
Velocity is a phrase that can actually make an impact on a budget committee. The case could be made that velocity will improve by 15% this year if we spend 20% of the engineering team’s time for the next two quarters on code quality issues. To get this data, simply ask each engineer roughly how much time they spend routing around technical debt.
In order to understand the timing of a budget request, it’s important to keep in mind the growth stage of your company. What passes for quality code in a Series A startup is not the same as what will pass in a Series D. When iterating on product/market fit it’s not uncommon to have a tangled web of spaghetti code, as this closely mirrors the twists and turns the business has been making in trying to perfect its value offering. Making an argument to clean up code when the business might pivot 180 degrees next week likely won’t make a lot of sense to the budget committee. Conversely, when a business begins to hit the J-curve and growth is projected to accelerate, putting time in to clean up code to allow for 100x scaling behavior has a strong chance of making sense to a budget committee.
Final thoughts
In summary, does the business care more about the short-term or the long-term? How important are things like reducing the cost of customer acquisition, increasing future velocity, reducing churn, and decreasing recruitment costs? Whether you’re currently a CTO, VP of Engineering, Engineering Manager, Lead Engineer, Engineer, or even an Apprentice, thinking about the business’s bottom line will help you build trust and put you in a better position to get the budget for that technical project that you’ve been itching to tackle.
Want to learn more about technical debt?
thoughtbot is hosting a live-streamed speaking panel with some prominent tech leaders on Friday, July 24 at 12pm EST. Registration is free and available here. Our gracious panelists are, in no particular order:
- Maria Loughlin, VP Engineering, Toast
- Neil Bhay, VP Technology, Tunecore
- Jim Studer, CIO, Univision
- Susan Dikramanjian, Director of Engineering, John Hancock
It’s going to be a lively conversation and a great way to spend the lunch hour. Come and join us!
Thank you to our speakers, and to everyone else who was kind enough to offer their insights during the research of this article.
