Hey 👋 this is Luca! Welcome to a ✨ weekly edition ✨ of Refactoring.

Every week I write advice on how to build great engineering teams, backed by research, case studies, and my own experience.

If you want to receive a full article like this every week, consider joining other 16K tech leaders and subscribe to Refactoring!

The full subscription also gives you access to the private community and the curated library.

About a year ago I stumbled upon an old video by Ward Cunningham, one of the original Agile fathers, about technical debt.

There he described debt as the natural result of writing code about something we don't have a proper understanding of.

If we fail to make the program aligned with what we understand to be the proper way to think about our [...] objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.

The video and the quote above inspired me to write a full article about the elusive meaning of technical debt, which as of today is still my most popular article ever, with more than 50,000 views.

The article focused on what technical debt really is and how you can prevent it in various scenarios. It did little, though, to help you address and reduce debt once it’s there.

This new article is a practical, thorough guide to managing technical debt with your team, from the quarterly strategy down to the day-by-day.

It covers:

• 🔥 The impact of technical debt on your team

• 📈 How debt changes with product maturity

• 🏃‍♂️ How to address it: small vs medium vs large debt

• ⚖️ How to assess technical debt

As always, the article takes from my own experience, plenty of readings, and conversations with the best engineers I know.

Most of all, it is a joint effort with folks from the Refactoring community, who have been invaluable in sharing real-world processes and examples (shout-outs inside the article). You can find here a sneak peek of the main thread.

Let’s dive in 👇

🔥 The impact of technical debt

We all have an intuitive understanding of how technical debt can drag down engineering teams, but how so?

I talked with Alex Omeyer, who surveyed 200+ engineers and managers around technical debt. Here are the insights that struck me the most:

• 58% of companies have no process for managing technical debt.

• 66% of engineers believe the team would ship up to 2x faster if they had a process for technical debt.

• 52% of engineers believe that technical debt negatively impacts their team’s morale.

Quoting Alex:

I was surprised to see such high numbers, but I can empirically validate them. Think of it this way: how many times have you estimated a feature would take the sprint, and it ended up taking two, or three? Now imagine this at the scale of an entire company and the ramifications it would have. It’s not hard to believe that companies who truly have a good handle on their technical debt ship twice as fast as those who don’t.

Technical debt mostly affects velocity and morale — and companies that have processes to address it constantly outperform those that don’t.

Is all debt created equal, though? Does this stand for all products and companies?

📈 Technical debt vs product maturity

When it comes to startups and fast growing products, you may hear about taking on debt intentionally, as the result of prioritizing speed and growth over engineering quality.

Regardless of whether this would make for a good strategy, debt is most often inevitable rather than intentional. Fast growth, in fact, naturally leads to technical debt, because when the product changes at a fast rate, your engineering abstractions get invalidated equally fast.

Such volatility, though, changes with the maturity of your product. For the sake of simplicity, let’s consider three stages:

• 0 to 1 — you start building a product from scratch, with a set of initial assumptions.

• Product Market Fit — you figure out what works, double down on it, and scrap the rest.

• Scale — you grow your business predictably and harden your tech.

The earlier you are on this scale, the more your product needs to move fast, and the more leverage you get by accruing debt.

The later you are on the scale, the more debt becomes a drag that prevents your product from growing. Your scale is such that you get the most leverage by repaying debt.

For early stage startups it might be inevitable and even healthy to accumulate debt early on. At the same time, though, you should create processes to help repay debt from the very beginning.

Let’s talk of processes 👇