Saying no is just as important as saying yes.

There is no value in reinventing the wheel, and not doing so gives you time to do other things that will give you value so someone should always be asking the question of if something should be done.

I mean it's a bit absolutist but that's to make a point; it's like the antithesis to Jim Carrey's Yes Man. A lot of developers are over-eager, simply looking for opportunities to work extra hours, pull an all-nighter, and show off to their peers. A lot of companies are over-eager to keep cramming features into their product, to keep pumping up those numbers, to build and release more and more services and products.

The nuanced point of view is of course in the middle; don't pick up more work or responsibilities without knowing the full story, without having done due diligence, homework, looking at alternatives, etc.

When I say "sounds like hell" I'm not necessarily looking at it from the point of view of what's economical, but rather from the point of view of job satisfaction.

Like: If a decision is made not to automate something, someone is going to have to do that boring repetitive work that could have been automated. The person making that decision not to automate is usually not the same person having to do that work. -- The former will usually be some kind of manager or owner, while the latter will usually be some kind of IC-level engineer or bookkeeper or something like that.

If a decision is made not to build that feature that a lot of customers requested, someone is going to have to explain to customers on a regular basis why they can't have their wish (usually some kind of sales person or customer service representative or something like that).

That's where the sadistic element of the Mordac character comes in.

There's a related problem that is discussed at length in the book "Peopleware" [1]: Often, from a strictly economical standpoint, you might be in a situation where you'd say "quality level x is the quality level that the market is willing to pay for, while any higher quality level is uneconomical". You might then be tempted to ask your employees to dial down the quality level of their work and produce worse work than they're capable of. -- The book argues that this is almost always a bad idea because of the demotivating effect. You'll get lower productivity and won't realize the cost-advantage you were hoping for in your purely economic analysis. Or to put it differently: Dialling up the quality-level in your product from the level you economically need/want to the level your employees are capable of will often pay for itself through increased productivity through increased motivation.

So, if you ask your employees to be 0.1x employees, you will truly get 0.1x employees. But the result won't be that you'll accomplish more with less, but rather that you'll do less and accomplish less due to lesser productivity.

[1] https://a.co/d/38NbxtG

"If a decision is made not to automate something, someone is going to have to do that boring repetitive work that could have been automated."

You did read the little sentences under the big bullet points, right? It's "first, let's see if it's smarter to not do the work at all, before we commit to automating", not "don't automate the boring stuff"

I did read that relativization, it just didn't pass through my bullshit filter.

This is because of a lifetime of managers telling me things like "before we do this thing that you want to do, please first conduct a fact-finding mission to consider the possibility that we don't actually need to do it". My mental bullshit filter turns that into just "no".

That's because the fact-finding thing only has two possible outcomes: I come back with evidence to support their no-position in which case: great job on that fact-finding. Or I come back with evidence to support my yes-position, in which case, guess what, there's something wrong with my fact-finding. Then they decide "no" based on their preconceived notion, plus they get to look very reasonable and evidence-driven. -- Conversely, a "yes" always looks very different. It's always "yes" from the start.

For me only the last one is a big red flag.

Apart from this, I'm of the opinion that one crucial job of a team lead/manager is protecting their team and, their product.

One way to do this is saying "no" to feature requests, being mindful of which hype to follow and balancing the value and the cost of doing so, etc.

"Before we automate it, we should think about if we can avoid doing the task altogether" is a red flag to you?

Sounds like Bartleby the scrivener, "I would prefer not to."