[throwway120385]

> 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 environment. And being a good manager means understanding when the health of the business is really at stake or whether the sales team is just throwing shade because they don't want to sell what the company has.

[ebiester]

So, I absolutely agree here that an engineering manager has to have the insight to tell truth from catastrophising on both sides. At the same time, I've seen sales orgs drive a department into the ground where everything comes to a screeching halt. I've seen times where that "feature X" is vaporware. Times when feature X is possible there because of different architecture choices. Newer entrants who learned from the older entrants. Features that look great for smaller customers that can't scale.

And all of those might be plausible answers. As you'd agree, nuance is key here. However, that is all from the department or product head. Now consider the CEO's perspective that has 8 equally loud voices all clamoring for resources.

My point is that it might not be disrespect but rather a management team that is trying to navigate competing priorities and economic realities.

[nradov]

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.

[pc86]

"Some portion of your time is reserved to work on whatever you want to work on with no input from outside your small team" does not work long term and it does not work at scale.

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."

[nradov]

Nah. I've seen that kind of capacity allocation work just fine on large teams and programs. It's not "whatever you want", the tech debt payments still have to be justified with escalating levels of approval required depending on effort and risk.

[kemiller2002]

This is an important point. Many people lose sight of the idea that tomorrow doesn't matter if you don't survive today.

[anonfordays]

This comment shows great understanding and experience. Too often engineers treat work like their pet/FOSS project and forget it's a business, and businesses are in business to make money, not pretty code bases.