I've found the first, and most important, step for any team or organisation to eliminate concerns with NFRs, "tech debt", and whatever else it may be called, is to stop giving it a name.

I'm being completely serious. By giving it some kind of distinct name, you are giving license to it being ring-fenced and de-prioritised by someone who doesn't (but, arguably, probably should) know better.

Quality matters. It hits your P&L very quickly and very hard if you don't maintain it. So it is as important as any other factor.

> amounts to being a functional requirement, in practice, over anything except the shortest of time horizons

Right! The unfortunate thing is that many software companies don't seem to think much further than a quarter ahead, not really.

Sure they might have a product roadmap that extends for a year or two into the future, but let's be honest. Often that roadmap is mostly for sales purposes, not engineering planning purposes. Product and engineering will pivot if sales slump. The earlier in the company's lifespan, the more likely this will happen often

However if companies get out of this startup mode then they should start to stabilize... But many don't. They continue this pattern of short sighted short term planning, which means product stability remains a low priority effort.

Ultimately I guess many companies just either do not have the resources to build good software or do not actually care to