I tend to agree, as I've seen it used and misused from both sides already. While the higher echelon often misses empathy for technical debt, what they need rath

I tend to agree, as I've seen it used and misused from both sides already. While the higher echelon often misses empathy for technical debt, what they need rather than a "euphemism treadmill" is real and actionable education on the _cost_ of technical debt. Likewise, engineers do tend to refactor everything and their mother when left alone with too much time and with too little education on opportunity cost and context on the big picture. The best advice I can give is first creating awareness and secondly making nonfunctional requirements part of any product negotiation. Always quantify the implicit expectation "...and it works": How long, for how many people tops, with how much possible downtime,... More often than not, business stakeholders can get away with much less than engineers think. That way, lots of technical debt and bad examples of overengineering never come up. But it's too late (and eventually, all code ends up as legacy code), these days I follow the school of https://martinfowler.com/bliki/OpportunisticRefactoring.html https://martinfowler.com/bliki/OpportunisticRefactoring.html Collect a few things that could be done way better / faster / stabler, ... — and then just convince everyone that a better architecture is the best way to get there.