I've never worked at a company, or even on a team/project, that didn't suffer from and generate "technical debt" in some way, shape, or form. These days, there's no avoiding it. Our industry is moving too fast across too many dimensions for any team or person to keep up.

Did you upgrade your app's web framework to the latest version? Great! Unfortunately, while you were doing that, a new version of your team's automated test runner was released. Oh, so you've upgraded that too now? Look at you! While you were wasting time on that, a new LTS of your app's runtime language dropped. Also, security vulnerabilities were just identified in three of your app's open-source dependencies. By the way, the SRE team just decided to move your company's infrastructure into Helm Charts & Terraform Modules. Can you partner with them on this, or will next week's deadline for launching that new product feature be jeopardized if you do?

If this type of charade sounds all too familiar, you're not alone! Engineering teams at every company across every industry are faced with similar circumstances every week.

The truth is, there often are no easy or "correct" answers when it comes to how a team should juggle those competing priorities effectively. More often than not, it will be the product-driven or business-justified work that gets prioritized first in scenarios like these. And you know what? That makes sense. Most of us are not employed to build idealistic, "perfect" software systems. We're paid to build something of legitimate value for our company in pursuit of its purpose. But alas, just like that — technical debt is born!

As engineers, we learn early in our careers just how awful and bothersome "technical debt" can be. It's the reason why you might be told that you can't do something you'd like to do, or why it takes so long for your team to complete a task that should be quick and easy.

We all know it, and we all hate it.

Surprisingly, however, most engineers seem to be far less familiar with the concept of "technical leverage." Why is this? To be honest, I'm not entirely sure — What I do know though, is that technical leverage is the best weapon we have in our arsenal for battling effectively against large-scale technical debt within our organizations. Given that, I think it's worth exploring this concept further and helping to spread the word!

While technical debt hinders progress, technical leverage promotes and accelerates it by enabling the creation of reusable and extensible components, frameworks, and libraries that can be leveraged across multiple projects and teams.

By investing in technical leverage, a company can reduce the time and effort required to build new features and products, improve overall code quality and maintainability, and ultimately improve their teams' ability to innovate, deliver business value, and attract top talent. However, investing in technical leverage requires a significant upfront investment of time and resources. This includes empowering engineers to develop an understanding of the broader, systemic issues impacting multiple teams and ascertaining the root causes of those issues. It'll also require a cultural shift towards longer-term thinking and encouraging the pursuit of engineering excellence.

To simplify, consider every engineering team at your company as a lumberjack cutting down trees (projects) with an axe. If you tackle org-wide technical debt by having each lumberjack dedicate 20% of their time towards it, many will spend time re-sharpening their axes or grabbing new ones.

Instead, imagine sending someone to a hardware store to purchase chainsaws for everyone. This is what technical leverage looks like!

So the next time your team considers addressing your existing technical debt with a quick and local fix, think carefully. Would you be better off in the long run if you left that debt alone and instead focused your efforts on building technical leverage that would yield dividends across multiple teams in the future? If so, that investment in your future might be worth the risk! At the very least, it'll certainly be worth having the conversation with your team and ensuring the tradeoffs are acceptable.