The Modern Leader
The phrase “technical debt” has such a negative connotation for something that happens in basically every organization. I mean, the word “debt” is literally in there. We typically think of technical debt as any sort of unplanned or unscheduled work that needs to be done by an engineering team that you’ve accumulated over time as a result of other actions made - whether it’s productionizing a patch (yes, we all have those “temporary” fixes) or upgrade packages within your repo, this engineering-driven work always holds a very necessary part of your overall roadmap.
And yet, the problem is making a strong case for allocating resources to technical debt to others at the company. You’re often up against an endless list of product-driven functionality requests, customer commits, and of course bleed-over work from the previous quarter/planning period. When you’re deep into planning and you’re trying to sell what one might consider technical debt projects when you have limited resources, aim to reframe. You’re typically not wanting to dedicate engineering resources to something that won’t have some sort of impact on your team or the product. You need to make it clear what benefit(s) you’re bringing to the table by investing time and resources into engineering-driven efforts.
Want some concrete examples?
Do you need to spend time upgrading packages in a key repo for your product? Great, you’re improving the reliability and security of key infrastructure by keeping it up to date.
Want to invest time in improving page speed? There’s a clear customer benefit here, particularly for your larger customers. Big win.
Eager to explore migrating your role-based access control system from Service A to Service B? Again, the answer is not “just because” — lean into the security, feature, and cost benefits and how Service B contributes to the overall company vision and direction.
Want to rewrite an entire section of your product because every engineer who touches it complains about how much of a mess the code base is? Think of the developer productivity! Investing time up front will lead to faster and more reliable deliverability in the future, and the potential for growth of this particular section is extensive.
See? You can really apply this type of thinking to any sort of “technical debt”. As you think through your own engineering wishlist, apply these questions:
- Does this task have security implications?
- Does this task impact the user experience of the product?
- Does this task improve the overall reliability of key systems?
- What do we lose out on if we don’t do this?
You won’t be able to get every item on your list added to the upcoming sprint/planning session (we know everyone has an endless list), but hopefully this exercise helps you think through key implications of your engineering work.