Earlier quoted context omitted.
> Someone who says no for too long doesn't last. I actually think the engineering manager is probably in the wrong there, because if killer feature X is that critical to sales, then it needs to be prioritized in among the tech debt. It doesn't matter that the codebase health is not great if sales plummet. Being a good employee means sometimes prioritizing the health of the business and not the ergonomics of the work…
In most organizations the engineering manager would share that prioritization responsibility with a product manager who acts as the voice of the customer. One simple approach is to just divide team capacity into two buckets: 80% for new features and customer bug fixes, 20% for tech debt. The specific percentages can vary based on circumstances.
Even among engineering software is somewhat unique in that we intentionally make sub-optimal decisions and then expect other departments not to raise an eyebrow when we demand time away from the next set of features to address (some of) those decisions, usually introducing more sub-optimal decisions in the meantime.
Nobody has figured out a better way to do it but it's easy to see why non-technical people would be inclined to think tech debt is just a way to do less "real work."