Hello and thanks in advance for reading Lessons in Engineering Leadership! If you’re new here, Lessons in Engineering Leadership is a weekly newsletter covering a variety of engineering leadership topics that can be read in under 5 minutes.
If you find value in these newsletters and would like to support this publication, you can become a paid subscriber.
I’m glad you’re here!
I’m fundraising for St. Jude Children’s Research Hospital while training for my first marathon (2024 Bank of America Chicago Marathon in October). Support my fundraiser here.
Reframing technical debt
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.
What I’m reading
Back to reading Wiring the Winning Organization! By the next newsletter I should be done with it.
Check out the full book list for recommendations and an ever-growing reading list. This is due for an update - I’ll be doing that soon!
Note: Links to books in this section are affiliate links to help support the purchase of the rest of my books :)
What I’m working on
I’m preparing for a week with my team in Poland next week, followed by a week and a half on vacation, so I’m playing the dance of getting all my work in a good place before I’m working in a vastly different time zone and then I’m out. I’m excited to spend time with my team, though!
I’m also SO CLOSE to finishing our 2023 SOC 2 Type II audit. So close.
If this email was forwarded to you, be sure to subscribe to receive weekly emails in your inbox that can be read in under 5 minutes!
Sorry, but I don't think those examples are really technical debt. They are just routine maintenance projects. By your description, anything could be technical debt.
Real technical debt is a substantial risk to the business in some way. Something that comes up in company wide executive meetings because it is a such a big deal.
For example, the code is on an old JS framework that is unsupported and you can't hire anyone to work on it anymore. Or you are behind on the version of Elasticsearch and it will take months to do the upgrade.
Real technical debt projects are big major problems.