So what is the actual definition of technical debt? Here are some I’ve found.

With borrowed money you can do something sooner than you might otherwise, but until you pay back that money you will pay interest. I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea. But that of course you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

The implied cost of future reworking because a solution prioritizes expedience over long-term design. - Wikipedia

Something (a data structure, an algorithm, a way to organize code, all the way up to a choice of language, framework or other technology) that was the right choice at the time it was chosen, but is no longer fit for purpose in the face of the ever evolving demands of the business - Thilo Rusche via email

The best definition of technical debt is “An obligation for future technical work.” It’s not “bad code” or messy data, though those might comprise it. - Jack Danger - Executive Engineering

I like Jack Danger’s framing of it as an “obligation”. It’s something you’re going to have to do. If you don’t it means not being able to meet the goals you’ve set.

How and why the debt appeared, and whether it’s been worth it, is a separate question to what you’re going to need do about it.

What technical work are you obligated to do in the next few weeks, months, and years?