I saw a few startups making plans for the new year ahead and allocating significant chunks of their time to tackling “tech debt” or “keeping the lights on.” Some resources claim that 50% of startups spend more than 40% of their time on this, while only the top 10% have this down to a whopping third of their time or less. That’s an almost depressing statistic and is extremely bad both for ROI and motivation. Let’s talk about drastically changing that number.

Not Real Debt

The thing about real debt is that the problem is continuously getting worse until you eventually address it. Debt has interest, meaning we can choose to ignore it, but at the cost of the problem becoming worse. If we’re honest, that’s not really the case for what we tend to call tech debt. That’s why so many banks still have systems in Fortran or COBOL: just because it’s old and possibly no one knows how to maintain them, doesn’t mean it’s necessarily not good.

Add to that the fact that we’ve admittedly gotten quite loose with the definition of tech debt in recent years. You have some part of your system that was written two years ago and isn’t using all the current best practices of React? “Tech debt!!” I recently heard there are mission-critical systems in my army unit still running on top of the framework I shipped in Java 5, about 18 years ago. Had it been real debt, those banks, and my unit would’ve gone bankrupt. All this to say a lot of fear we have about the urgency of tackling tech debt is misleading and we can put it aside.

Whack a Mole

As part of our relentless fight against tech debt, some teams spend a mind-boggling effort to always keep things up to date. I remember startups that regularly spent days updating a hundred or so microservices to fit their latest conventions or making minor version updates—along with all the testing necessary—for no real reason. A third of those were essentially “complete.” They were not changed and for all intents and purposes could’ve been left alone, especially those that were entirely internal.

I’m not saying you should let everything rot, but tech leadership is about more than seeing things as binary yes/no decisions. You should assess the risk entailed in letting a certain part of the system be left behind as opposed to the cost of shuffling things every time there’s a change. How often did you see teams throw away entire services and systems after a few years because things have changed so much that it’s easier to rewrite than to keep patching things? That’s not necessarily a bad thing (as 37 Signals would demonstrate). There’s so much sunk cost into maintaining services that can make us stick to things past the point where it no longer makes sense. Invest in what requires tackling debt, not automatically.

One caveat is that perhaps within a couple of years, AI will make this continuous maintenance task less of an issue. When that happens, we can readjust our approach. In the meantime, spare your precious human time.

Refuse the Easy Path

Putting a bunch of things on your roadmap because it’s “tech debt” is the easy way out for managing your team. You want to feel like you’re being professional, you want the team to have a good feeling about not having any code that’s legacy code (how did that become a bad word anyway). However, if we allow anything that’s tagged as debt to be added into our sprints because we have some time to address it, it means we’re necessarily missing out on better opportunities.

Real leadership is about the annoying art of “it depends.” Sometimes the effort makes sense, but other times it’s just feel-good busywork. Our role is to be there to help choose the valuable changes and separate the wheat from the chaff. To do so, I highly recommend dropping the hard-set time dedicated to these efforts. Instead, have the team explain the reasoning and value behind these and prioritize it as you would any other task with Product.

It might feel like tackling all your debt is the “right” thing to do from a purely software-engineering mindset, but it’s rarely the right thing for the business.

Stop Using That Name

Lastly, there’s our tendency to use this name to describe too many things that aren’t really tech debt. For example, if you think a certain micro-service should be optimized because its slow queries are dramatically affecting user experience, then go ahead, but don’t you dare call that tech debt. Any work that immediately results in an improvement for the users can’t be called tech debt.

In my book, tech debt is about parts of the system that are written in a way that’s not ideal or obsolete, which makes the engineers’ day-to-day work more cumbersome. Tackling it doesn’t result in immediate functional improvements for the clients, but serves to make the product as a whole easier to maintain and improve.

If you fear this means you’ll have to collaborate much more with Product and explain a lot of things you nowadays just do with your allocated time, you have a bigger issue at hand. Using tech debt as a catch-all excuse to avoid having to speak “business” will only harm you in the long run. If you need help with that, reach out.