“Too much technical debt.”

Whenever I work with a team, this is overwhelmingly the biggest problem cited by leaders and developers alike.

If you’re a developer (or have been one in the past), chances are this resonates with you. And if I ask you what technical debt is, you might pause to think for a bit, but you’ll come up with something.

On a recent project, I asked about 35 people (almost all managers who were previously senior/staff engineers) how their teams classify technical debt. This group had so many common traits – same company, same job – yet there were no two common answers, and even some spirited disagreements about the definition of tech debt.

“We know it when we see it.” Most developers (and former developers) have a bit of a spidey-sense when it comes to identifying technical debt. However, this does not serve us well when it comes to communicating the need to address technical debt to outside stakeholders. If we can’t even define it, how can we expect someone else to get on board?

What worries me a bit more about this lack of common definition is that technical debt is being studied more and more (a good thing) and now there is more concrete proof of the negative impact of technical debt – namely slow execution, poor quality, low morale, and even low self-esteem in developers (a bad thing).

It’s hard to choose interventions to prevent these poor outcomes if we don’t know what we’re up against.

Just ask them

Before going any further, I will fall back to the advice I give in almost every scenario: ask your team.

It is somewhat irrelevant if the “academic” definition of technical debt includes or excludes, for example, addressing security issues. If your team perceives security issues as a form of technical debt, it is. It is still going to result in all of the negative effects discussed above.

Talking to your team may seem like an obvious suggestion, or perhaps even silly. But have you ever asked the question “what do you consider to be technical debt?” before asking the question “are you satisfied with the amount of technical debt on our team?” Most teams haven’t, and you might be surprised by the conversation.

Defining technical debt

As with many things in software development, we can look at the pragmatic side of things (what’s going on in practice) or the dogmatic side (what the theory says).

Pragmatism always wins with me, so let’s start there.

My definition: the negative result of intentional or unintentional suboptimal decisions when building software.

Breaking it down a bit more, there some key variables at play in that definition:

• Negative impact or friction

• Quality of the decision

• Time

• And a wildcard: perception of team autonomy

Negative impact

You might choose to take out a loan to buy a house or a car instead of waiting an extra 5, 10, or 25 years to save up cash. So this was overall a positive decision for you, but it does carry some negative consequences: you’re going to pay more over time. Technical debt also comes with negative consequences, whether it’s slower development times, lower quality, or something else. This negative impact is crucial in defining technical debt. If there’s no friction or pain, that debt is essentially “free money,” and it’s hard to argue to pay it back immediately.

Quality of the decision

The decision leading to that negative result was suboptimal, but it may either be intentional or unintentional. Additionally, your team may not have been responsible for making the suboptimal decisions, yet needs to live with the consequences. I’m sure everyone reading this can think of an example where the business urged a feature to be released on a tight schedule, which contributed to technical debt.

It’s also hard to predict future business needs, which is why I mention both intentional and unintentional decisions as a factor of technical debt. Your team may knowingly need to postpone maintenance work, causing it to increase in scope and complexity once you have the time to get around to it. This is suboptimal but intentional. You may have also made a design choice early on in your product’s life that no longer serves the business, and your team feels like they’re continuously building on top of a system held together with toothpicks and duct tape. These decisions are still suboptimal in hindsight, but the effects were unintentional.

Time

Time plays a role. There are so many projects that we might exclude from our definition of technical debt on day 1, but on day 1000, they are absolutely technical debt. Postponing maintenance, dependency upgrades, or security issues would fall into this category. Across the 35 technical leaders I spoke with, I asked the question, “when does maintenance turn into technical debt?” Some leaders classified all maintenance work, even predictable routine maintenance, as technical debt. The majority settled on a definition similar to “if you wait too long, it becomes technical debt,” which is what I generally agree with. In this definition, we need to relate the suboptimal decision (postponing maintenance work) back to a negative result (lower quality, security risk) in order to consider it technical debt.

Lack of autonomy

There is one wildcard here: perception of team autonomy. I’ve written and spoken about how self-perception matters much more than we think it does when measuring productivity and other factors of software development. Oddly, technical debt is not an exception here, even though it feels like it should be something easier to objectively quantify.

Teams may still be unhappy with the amount of technical debt they have if they feel that they are not able to propose and execute on self-directed projects. In this situation, the definition of technical debt isn’t the one that I mentioned above, but rather a perceptive measure of how much control the team has.

If we don’t have control over what we’re working on, we must be accruing technical debt, because only we would know how to avoid it.

This is a sticky situation to be in as a team. Some leaders have asked me, “how can I help my team advocate for refactoring this piece of architecture that really bothers them? We know it’s the wrong design.” When we go through the evaluation criteria, inquiring about the negative result of not doing it, considering the severity and occurrence of those consequences, sometimes the team comes up empty-handed. There’s no compelling business reason to repay the debt now – and a question might be raised about if it should even be considered debt if it’s not having a negative impact on delivery or quality. These are uncomfortable conversations to have as a team.

Now, since we know more about the human impact of technical debt, specifically how it can tie into loss of productivity, low morale, and developer turnover, there is potential to develop a stronger argument for taking on these kinds of projects. Even in a cooler market like the one we are presently in, developer attrition is an expensive problem.

What research says

Usually, technical debt is described as a metaphor to compare the phenomenon of suboptimal development conditions to actual financial debt, where one must pay interest. Technical debt does also have real monetary cost, which is why it’s so interesting to businesses. At this point, these costs have been studied more extensively than the human factors, though that is changing in recent years (besides “just ask them,” my second rule is “everyone speaks money”).

I can best summarize the dogmatic definition of technical debt as “suboptimal choices that cost money.”

In practice, my observations are that most development teams, even in small companies, are too far separated from these types of financial models to reason about technical debt in terms of revenue, but absolutely do feel the pain of technical debt in their day-to-day work (even if they can’t quantify it in money).

What you can do next

Trying to reduce technical debt on your team?

• Ask your team about what they consider technical debt and develop a common definition

• Consider adding better descriptors to things you’ve labeled as technical debt. Is the issue related to security, reliability, scalability, or something else?

• Speak money if you can. Can you quantify the impact of the project in cash?

• Coach your team to get better at advocating for technical debt projects with stakeholders

• At the same time, call out that technical debt creation will be a byproduct of certain business decisions, and state it as an explicit risk to certain decisions