[dasil003]

Although this article points out a lot of mistakes that can be made when talking about technical debt, it kind of throws the baby out with the bathwater.

The truth is technical debt is a metaphor specifically designed to be understood by non-technical business people. Technical debt has gained traction as a concept because it does actually give a reasonable indication of the cost tradeoffs of short-term vs long-term implementation decisions that was formerly very difficult to explain.

Of course, all analogies are flawed, and the devil is always in the details. Over time "technical debt" has been used to describe all manner of problems which don't really fit the rubric as interpreted by a business person, for instance: changing requirements, UX debt, bitrot, junior coders, bad guesses about the future, etc.

What it boils down to is effective communication: the mental model of your audience, and your reputation. If you are in an org where there is no understanding of technical quality and no trust in engineering, then the assumption will always be that you're sandbagging, and frankly this is no place for an honest hard-working engineer to be. On the other hand, even if there is a strong engineering culture with a CTO who understands the details and has an equal voice at the table, you can't just cry "technical debt" at every turn because engineering is more complicated than that. There are usually paths to deliver value while improving quality over time, but sometimes it requires different kinds of pushback. Reframing the problem with alternate sequencing or 80/20 proposals to product or business stakeholders is often more fruitful than endless negotiations centered around resource numbers. However it all stems from trust. If you as an engineer or engineering manager can demonstrate you understand the needs of the business and can more efficiently transform engineer hours into business results, over time that gives you the reputation to be heard when it comes to long-term tradeoffs.