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.
Planning for tech wealth
Once teams have allotted engineering capacity to new feature work, there’s often little time left over for building tech wealth. Assuming you can’t just pause feature work—although I’d love to see an engineering team try!—the following strategies can help teams start incorporating tech wealth into the planning process.
Allocate time within each planning cycle
Does your engineering team use a fancy formula to determine how much capacity you have for development work during each planning cycle? If so, consider allocating a small but meaningful portion of that capacity to building tech wealth.
The appropriate amount of time will depend on your team’s needs. For instance, if you want to increase integration or unit test coverage, assigning 80 percent of your engineering time to product development and the remaining 20 percent to building tech wealth might suffice. If your team needs to evolve the architecture or system to meet new requirements, you may want to set aside 60 percent of your time to build tech wealth and 40 percent for product development.
The advantage of incorporating tech wealth into every planning cycle is that it becomes part of your team’s regular cadence, which normalizes the practice. Your team can even begin to attribute success metrics to the wealth you accrue each cycle. For instance, you might track the number of bugs introduced before and after you invested in building out automated test coverage.
If you don’t use a fancy formula to determine engineering capacity, start simple. If your team is big enough—say, at least four engineers—one person can focus on building tech wealth each cycle. Consider establishing a rotation so each engineer has a chance to work on tech wealth projects while also getting to build the splashier stuff.
Regardless of the approach you take, be sure to define and document the value your tech wealth tasks produce. This will help sustain buy-in on these investments.
Dedicate the last few cycles in a quarter
If you can’t commit to a fixed amount of time each sprint, iteration, or planning cycle, you may want to carve out a certain period each quarter instead. For most teams, the end of the quarter is a suitable time to do this; once you’ve completed feature delivery or are in the process of A/B testing features, you’ll likely have more engineering hands free. As for how long that period should be, it depends on the wealth you’re trying to accrue. If you’re not sure where to start, try a couple two-week iterations, which should be enough time to start filling your tech coffers.
Unlike the first path I laid out, this quarterly strategy will require 100 percent of your team’s capacity, albeit temporarily. I’ve found it particularly helpful in situations where the investment required multiple engineers’ time and energy. This approach encourages focus and decreases context-switching, but it will take willpower—and some firm boundary-setting—to ensure business or product stakeholders don’t slide into your engineers’ DMs hoping for one last “quick change.” Another benefit to this strategy: You can use the time to tidy up any hacks or workarounds implemented earlier in the quarter, when the team was striving to meet product goals.
If you’re building tech wealth on a quarterly basis, you might find it useful to maintain a backlog of tech wealth projects for your team to consult. For example, you could create a Jira project or Trello board dedicated to keeping track of the wealth you plan to build. This will help keep your upcoming plans clear and your tech wealth goals in sight.
Create tech wealth, reduce tech debt
By planning for tech wealth, you are, in fact, diminishing tech debt. This subtle shift in perspective can give engineering teams and leaders a fresh outlook on this essential—but perhaps less glitzy—aspect of our work as software developers.
Where tech debt implies a lack, tech wealth suggests abundance: an abundance of security and stability for your systems, and an abundance of time and satisfaction for your engineers. Once you incorporate tech debt into your planning cycles, you can enjoy the benefits of this plenitude. You’ll be able to streamline your systems, increase innovation, and, ultimately, build better products for your users—even if they don’t necessarily behold all the gorgeous, glittering wealth you’ve built behind the scenes.