A long time ago, computer programmer Ward Cunningham introduced the idea of tech debt. I believe he intended to improve communication between technical and less technical audiences, using a term business people could relate to.

But tech debt was originally intended to be a metaphor. And as with any metaphor, there can be a lot of gray areas, requiring careful explanation so as to avoid confusion.

Today, I hear many teams misuse the term tech debt and want to identify some common traps you can avoid, as well as alternative terminology you should use.

Avoid: Tech debt without explanation

There is often an assumption that business people are already familiar with the term “tech debt” because it’s so regularly used. Product managers hear phrases like, “We have tech debt,” or “ We need to pay off tech debt,” and “We are taking much longer than estimated because of tech debt.”

But just because these phrases are commonly circulated throughout organizations, that doesn’t mean they are truly understood by everyone. This is especially true of less technical people who might not have an extensive grasp of the concept. For them, being provided with context and specificity are really important. If you’re someone with more technical expertise passing on an update to someone less technical, consider practicing empathy to guide you in providing the most helpful information so they can evaluate a situation’s severity and the impact of tech debt accurately.

Do: When discussing tech debt issues with non-technical folks, make sure you are pointing out what sort of problem you are dealing with and its significance. It might be as simple as saying, “Over the last month, our team lost three days addressing defects on an older part of the system without automated tests. If we spend one day writing tests, we can avoid losing this time each month in the next few months.”

Avoid: Tech debt without a return on investment

Engineering leaders are often faced with complaints of tech debt from their teams. When they come to me with the queries they’re confronted with, the conversation usually goes:

• Engineering leader: “My team complains about lots of tech debt.”
• Me: “Can you give me a concrete example?”
• Engineering leader: “Sure. For example, they complain about our notification system written in an older programming language.”
• Me: “That’s interesting. Besides being old, do you have any other issues in that area?”
• Engineering leader: “What do you mean?”
• Me: “For example, do you have a lot of defects in the notifications, or are you actively working in the notifications part of the system?”
• Engineering leader: “No. It’s extremely stable, and we never have to touch it.”
• Me: “What would be the benefit if you rewrote the notifications system?”
• Engineering leader: “Well... it’d be newer. And the team would be happier.”
• Me: “Do you think this is a strong enough reason?”
• Engineering leader: “Probably not.”

So, what’s the takeaway here? All codebases of any significant size and age are full of imperfections. A codebase being old isn’t a good enough reason for it to be rewritten. However, if it were significantly impacting the efficiency of a team, that would be grounds to start changing things.

Remember, the team and organization should benefit from the change.

Do: Work on tech debt where you realize the benefit of the effort in the near term. If an area of the codebase is hard to work in, addressing the tech debt should also make it easier for a team to implement a feature they will work on in the next few weeks. Ideally addressing tech debt would also have an external benefit to users, such as a better user experience, or reducing the errors they encounter.

Avoid: Tech debt as an excuse to play

In many companies, less technical people believe that technical people invent unnecessary work, making features more complicated than needed. While this belief may not be fair from your perspective, it’s often grounded in experiences where a technical team prioritized playing around with new tech over achieving something with that tech.

Although I’m a big fan of company cultures that encourage teams to explore new tech and learn, folks need reminders that learning at the expense of a company’s overall goal to deliver high-value products to customers, should be avoided.

Do: Avoid the perception of “playing” with tech by pointing out the business benefits your tech brings. For example, “We introduced this new tool which enables users to self-serve customer requests and reduces our time supporting them. We save a day a week as a team as a result.”

Avoiding the term altogether

In technology teams, everyone has a good sense of the implications of tech debt. But ask individuals to define tech debt, and you’ll be faced with many different answers. If we can’t agree on what tech debt means, then folks outside of technology have no chance.

Consider avoiding the term tech debt and start using a term like friction. If your team is experiencing friction, you should be able to explain the effects in time or effort. If your team is not experiencing any friction, there shouldn’t be any reason to address it. 

Focusing on the friction that you can identify makes it easier to find support to address it.