"Technical debt" as a catch-all is not ideal, but it's usually an easier sell than "We need to start looking at and fixing the never-ending procession of short-sighted and slipshod decisions that you, management, and you, lazy developers, have apparently booked for a year-round appearance in our codebase."
The problem is that "technical debt" has no bearing on the business functioning of any company whose primary deliverable is not a piece of technology. At best, it's seen as a sort of odd thing that suddenly causes schedules to slip and engineers to quit; at worst, it's dismissed out-of-hand and ignored.
There is really no good way of explaining to non-software-engineers why technical debt is a big deal in such a way that they prioritize it as something to be addressed. The article's suggestion that you break it down into actionable items fails: technical debt can't be explained in terms of any individual issue, because the problem isn't any particular issue--and if you try to do it that way, each issue invites a hacky solution that drives you further into debt!
It's a culture, it's craftsmanship, it's ownership, and it's quality that are attacked by technical debt. It's how you guarantee that only malicious geniuses and shitty developers stay on your project.
