Technical Debt - What It Is and How to Deal With It

We could easily write an entire book on technical debt, but for the sake of simplicity and actionable hints, I’ve aimed to distill the shortest and most comprehensive definition based on my professional experience.

What is technical debt?

Technical debt represents pain points in your tech stack that prevent you from achieving product or business goals.

Code quality, testing, automation, coupling, architecture, performance, and security can all be sources of technical debt. However, these only become debt if they block potential business outcomes.

Is a monolithic system technical debt? The answer depends on context. Yes, if it stops multiple teams from delivering effectively (due to strong coupling, a single repository, fixed release cycles, etc.). No, if a single small team works on it (because of simplified infrastructure and the ease of monitoring and maintenance).

How to tackle technical debt?

There are two general approaches to managing technical debt:

• Continuous Improvement: Every task should contribute to enhancing your tech stack, whether through better test coverage, removing outdated elements, or updating dependencies. Embrace The Boy Scout Rule and always leave the code a little better than you found it. While it's the team's responsibility to drive these improvements, your role as a leader is to set clear expectations for the desired state of the tech stack. Establish clear metrics, discuss progress, remove obstacles, and celebrate milestones.

• Large-scale Projects: Some technical debt is too complex to address in "20% time for tech excellence". In these cases, you must treat these initiatives as business goals and integrate them into the product roadmap. For instance, if re-platforming or migrating a monolith to a distributed system requires three months of the team's work, ensure the outcomes are evident since you ask for tens or hundreds of dollars in investment. You have to make management willing to make this change so you can focus on doing a great job rather than fighting for priority.

How to identify technical debt?

As an experienced leader, you likely have a sense of how things should be and are familiar with good practices such as continuous delivery, process automation, trunk-based development, and achieving 99.99% SLAs.

However, relying solely on intuition to identify technical debt is insufficient. You need two more types of insights:

• Qualitative Feedback: Data that can't be measured numerically, such as team feedback, biggest struggles, and suggestions. The best way to gather this is through 1:1s or feedback surveys with as many team members as possible.

• Quantitative Feedback: Metrics that provide numerical data on relevant areas, such as deployment frequency, incident counts, system stability, number of bugs, or duration of steps in your CI/CD process.

Technical debt: Actionable tips and further reading

Here are some actionable steps to better understand and manage technical debt:

1. Understand the company’s goals and direction to determine which parts of the tech stack hinder progress. Start with Four Factors Essential to the Success of Any Product.

2. Identify technical debt using a combination of:

   • Your experience and knowledge.

   • Industry best practices, such as those from Accelerate.

   • Numerical data, such as KPIs and observability metrics. For inspiration, check out: Practical solutions to track your goals.

   • Feedback from your team. Here’s the content that can help you: First Ten 1:1s for Engineering Leaders or Mastering the Feedback.

3. Classify technical debt using frameworks such as Ten Types of Technical Debt from Google or ThoughtWorks.

4. Address technical debt by:

   • Continuous improvement, applying the Boy Scout Rule. As a leader, define and track clear goals and success metrics.

   • Prioritizing larger technical debt as projects on the product roadmap. Work closely with management to ensure clear work outcomes and get buy-in. Consider using Amazon’s Working Backward/PR Release method to articulate the project and secure support from stakeholders.

---

How do you approach technical debt? Does this guidance address your organization’s needs, or is something missing? What challenges do you face in managing technical debt?

Feel free to reply or reach out to me at mirek@practicalengineering.management for further discussion.