A Framework for Thinking About Tech Debt

This post is for engineers, engineering leaders, and product managers.

My view of tech debt has evolved over my career. In this post I hope to provide a framework, based on analogical thinking, to help improve decision making around tech debt.

Like anything in life, systems need to be maintained in order to continue to operate efficiently. Take your body for example. If you eat poorly, don’t exercise, and don’t pause to reflect on what’s important to you in life, there’s a good chance your demands on the healthcare system will increase over time. Similarly, avoiding changing the oil in your car and never washing that winter brine off the undercarriage is likely going to reduce the functional lifespan of your car.

Constant investment is needed in order to combat the internal and external forces that act upon a system to push it out of equilibrium. Let’s take a closer look at these internal and external forces.

External forces (decay)

Systems naturally decay over time. Even a brand new shiny software solution has only a narrow window of time where it is perceived as being shiny. Soon, new technologies will emerge all around the shiny new solution and gradually cause the system to decay. Investment in the form of migrations and upgrades are required in order to keep the system in equilibrium.

Internal forces (tech debt)

Tech debt is the result of both intentional and unintentional changes to a system that violate contracts, boundaries, patterns, and other conventions. For me, tech debt is any change that is optimizing for short term gains and deviating from the longer-term ideal state. It’s difficult to define and align around an ideal state, but deviations from it are often obvious. For example:

• Small changes begin to take longer than expected.
• Multiple different ways of accomplishing the same thing.
• Strong collaboration and communication outside of the code in order to inform decision-making in the code (i.e., many Slack discussions, white-boarding sessions, and even meetings necessary to download the tribal knowledge necessary to increase confidence in changes).

For the remainder of the post, I’ll focus on tech debt. There are two different types of tech debt: intentional and unintentional.

Intentional tech debt (a loan)

You can think of intentional tech debt as an investment. This is just like taking a loan out to invest in a home. You don’t have all the cash on hand, but you know it’s a good long term decision (most of the time at least), so you ask the bank for some cash, at the lowest interest rate possible, to accelerate the desired outcome (i.e., get your home now, rather than later). You then make a plan to pay back the cash and amortize it over some amount of time.

Intentional tech debt works in a similar way. When we make the decision to accumulate tech debt intentionally, we’ve carefully considered the trade-offs and broadly socialized the intent to accumulate debt in order to move fast and accelerate the outcome (i.e., launch the project sooner, rather than later, so that we can accelerate our learning and know if a particular project is going to deliver business value). Similar to creating an amortization schedule for a mortgage, intentional debt tech should be tracked and prioritized accordingly.

Intentional tech debt is necessary. Sometimes we need to move fast and we need to make short term trade-offs to do that.

Unintentional tech debt (a loan shark)

Unintentional tech debt is the kind of debt we want to avoid. It is analogous to borrowing from a loan shark (high interest rates and severe consequences if the debt isn’t paid off). Unintentional debt is often the result of insufficient contracts, boundaries, patterns, and abstractions. These insufficiencies typically emerge at inflection points on a system’s growth curve. For example, a period of rapid growth in a business might result in rapid innovation in a system. This rapid innovation will introduce unforeseen challenges that will breed ad-hoc solutions that ultimately result in unintentional tech debt.

Takeaways

• Systems are always decaying. Reserve some amount of time for “keep the lights on” work. The time allocation will change over time. Sometimes it’s 5% of the portfolio (e.g., general software updates), sometimes it’s 20% of the portfolio (e.g., larger platform changes).
• Tech debt is natural and is expected. The goal is to minimize unintentional tech debt and to accept and elevate intentional tech debt. After acknowledging it and accepting it, we can take the next step and increase the visibility of this framework across senior leadership and product managers. This will ensure there is always time allocated for investment in paying down tech debt.
• Create a mission statement for your team. Create a vision. Define a technology north star. These artifacts will help you make local decisions that keep the longer term destination in mind. This will help when considering trade-offs for intentional debt while also help avoid unintentional tech debt. You can’t avoid unintentional tech debt, but there are things you can do to mitigate it.
• Invest in patterns, abstractions, guidelines, and best practices to help up-level the team and ensure engineers are aligned and informed. These things can be enforced through code-reviews, brown-bag sessions and other knowledge sharing sessions.
• When investing in intentional tech debt, consider, if the decision is easily reversible. If it’s easily reversible, don’t spend too much time on the decision. Document it and move one. If it’s not easily reversible, this is a good time to take a step back, socialize the problem and seek dissent. Force yourself to come up with 3 different solutions to solve the problem. List the pros and cons of each solution and document why the chosen solution is the best path forward for right now.
• Always reserve some % of time for tackling tech debt. It’s normal to have a healthy tension between technology needs and product needs. Make sure tech debt is always part of the conversation. This will help set expectations and help avoid bankruptcy (i.e., the system becomes riddled with tech debt and complexity and causes a stop-the-world investment event).

Get comfortable with tech debt. It’s not inherently bad. In fact, it’s necessary. I’d love to hear how you think about tech debt and other mental models & frameworks that have helped you build world-class solutions.