Reframing tech debt

Tech debt the two words engineers loathe more than deploying a “quick fix” on a Friday and product owners fear more than missing an OKR deadline.

Often, tech debt results from taking too many technical shortcuts when building out features. You know the drill: The product team creates an ambitious roadmap that leaves little room for error, and engineers hack on top of an already archaic software infrastructure to enable those ambitions. The debt creeps in like a child tiptoeing into the kitchen to sneak cookies from the pantry, resulting in a gradual erosion of your system’s efficiency and a whole lot of crumbs to clean up. When quick and dirty hacks become an engineering organization’s default mode, it can be tough to advocate for doing things the “right” way, dedicating time and effort to formulating detailed requirements, building robust solutions, or automating manual tasks.

Paying down tech debt is frequently seen as the less glamorous, less exciting side of software engineering. Migrations aren’t fun, and neither is replacing old dependencies with new ones. New architectures don’t magically diagram themselves on your whiteboard overnight. But when left unexamined for too long, tech debt can go from a neglected nuisance to a catastrophic failure. In contrast, when addressed proactively, tech debt represents an opportunity to build resilience and robustness into our systems.

That’s why I propose we rebrand tech debt as tech wealth.

Introducing tech wealth

Carving out time to pay down tech debt requires buy-in from leadership. Getting that buy-in is hard, especially since end users may not directly feel the impact of many tech debt investments, such as improved tooling or automated processes. In fact, many development teams have a pervasive misconception that since tech debt doesn’t impact the user, it’s not worth prioritizing. But in reality, addressing tech debt enables us to devote more time to feature development later on. Dealing with the system’s weaknesses up front means engineers will spend less time wrangling spaghetti code or solving neglected issues in the future. 

By framing tech debt as tech wealth, we can minimize the negative connotations associated with such debt and put these false impressions to bed. This rebranding can shift leadership’s perception of these vital behind-the-curtain investments, increasing the likelihood they’ll buy in on the work. In business, building wealth is something to be done as soon as possible, with great care and focus. Likewise, doing the fundamental work to make your systems stronger and more efficient should be viewed as worthy of up-front investment. 

Defining tech wealth

Wealth, by definition, is an abundance of valuable possessions, goods, or resources. For an engineering team, building wealth could mean increasing productivity, engineer happiness, system stability, and so on. When we understand our technical overhead in this way, we can focus on communicating value: What value do we get from spending time accomplishing a specific task or initiative? What gains or resources do we acquire as a result of that work?

Building tech wealth means getting more value out of the software we’re creating, as well as our efforts to develop and maintain it. When reframing tech debt as tech wealth, we can ask ourselves the following questions to clarify the value-amplifying opportunities available to us:

• What steps can we take to help our teams move faster and more efficiently?

• What can we do to improve our systems’ scalability or stability?

• What work could improve engineers’ experience maintaining those systems?

Let’s take deployment automation as a practical example. By dedicating engineering time to creating the infrastructure for automating production deployments, you might gain tech wealth in terms of increased speed to production (because users will receive new features or bug fixes more quickly), greater developer happiness (since engineers will spend less time manually deploying releases to production and can focus on more engaging work, like feature development), and reduced risk (by removing human error from the deployment process). This high-value investment improves the fortunes of your users, developers, and the system itself.