Much like we would stage an intervention, if a friend were obsessed with maxing out credit cards, we should stop focusing all developer attention on tech debt. There is a limit to the amount of debt that could be cleaned, but innovation is boundless. Let’s talk about spending some developer attention on amassing tech capital: abilities that serve the entirety of the organization and make everyone more impactful.

Shouldn’t We Cut Tech Debt?

Virtually every single R&D team out there is spending some time tackling its tech debt. I’ve worked with startups that complained about tech debt as early as one month since they started coding. Of course, you have to manage it, just like you cannot ignore loans with the hopes that they’ll disappear.

Nevertheless, for many, this fight against tech debt goes over the 80/20 principle. Instead of thinking about the proper ROI, organizations become dogmatic and spend an inexplicable amount of effort for a benefit that might not ever materialize.

I would like to see more of the excellent engineers around us directing their focus at endeavors that provide a tangible advantage. Making a place for more creativity and innovation is a must. After all, bright coders can do more than clean up code and update packages.

A Better Balance

You might be wondering what the alternative is. I believe that teams should make innovation habitual and use their creativity as a weapon. Your team is likely brimming with ideas and motivation, but they lack a way to express it. Teams gravitate towards tech debt and a technical focus because people look for an area where they have agency, connection, ownership, and impact. That can’t happen without conscious and active efforts to connect the team with the product and provide them with autonomy. Instead, engineers go through the path of least resistance for self-actualization: tech is where they have the most ownership and say, so they focus on that.

My suggestion is to create an environment that lubricates the chances of serendipity and allows for spectacular failures to happen—as long as they were worthwhile experiments. I wrote about this sort of culture in chapter 8 of The Tech Executive Operating System (which, by the way, you’ll get as a free sample chapter by following that link). The two most impactful tools for creating such an environment are Product Mastery and Intermissions.

Intermissions are sometimes called sabbaticals, innovation weeks, and so on. I covered them in this article, but the bottom line is that you make the team do things that aren’t part of the regular roadmap and that are more challenging than tech debt or bugs. During those weeks, we try to cultivate Tech Capital: tools and assets that make others in the company better, enable faster decision-making, or benefit the business directly. Think of internal tools, a new bleeding-edge technology that can unlock a new value stream, and so on.

Product mastery is about connecting your engineers (and everyone else, really) to the core of the business, the market, and the users’ needs. It’s about having the context which then allows people to make better decisions (and they’re making dozens of micro-decisions a day, think about those compounding). This mastery also makes innovation and creativity possible—it is a prerequisite for specific innovation that is related to your particular business, as opposed to generic technological innovation (i.e., something that could’ve been an open-source tool). You can find out more about product mastery here.

At the end of the day, creating such a culture is not really an option. Why would you want anything else? Why settle for a team that has turned into a Jira-resolving-machine that consists of tech debt fanatics? I’d choose a team that regularly innovates and cares about the business any day.