> …when you’re in a position to help

This clause is doing a lot of heavy lifting. One needs to have good judgement about when and how to help. A lot of people can imagine how things could go better if a bunch of other people changed their behavior in surprisingly simple ways. It's a much smaller subset of people that can correctly push the right buttons to get the other people to actually make those changes succeed at a systematic level.

In a small org it's actually not too hard for good ideas and feedback to get traction. In a larger org for broad concerns it can be fiendeshly difficult. Often the reason why a large project will fail is only truly knowable by a few senior technical people with enough experience and broad context to see the forrest for the trees. Past a certain volume of people involved you can not explain to people why it will fail fast enough to offset the army of clueless stakeholders incentivized to socialize a good-sounding narrative convincing everyone that we need to try. In these cases reductive explanations with the right counter-narrative can work, but they require significant reputational and/or hard authority to pull off.

This is why the article advocates picking your battles in a large org. Often the chance of actually helping is much lower than destroying your own reputation, even if you're right.

It depends on the context. If you're with a small organization and you're interacting with the project early in the development, it could well be your duty to explain your misgivings and why you think they should do things differently. If you're with a large organization and the project is already underway, it's going to take a lot of time and effort to redirect the project. That's time and effort that could probably be spent more productively elsewhere.

The point the author is making is somewhat maligned by the title "... let bad projects fail".

The point the author makes is that sometimes you are not in control of those projects. Therefore "letting them fail" seems a false choice constructed by the author.

A better title "You don't know what other people are doing and you don't know why unless it is your job to do so."

> If I see something heading toward failure, I let people know they may want to consider a different approach.

This is what I do as well, in writing. Then I drop it. Professionalism demands that I say something. That's part of what I'm being paid to do. But experience has taught me that it's almost certainly not going to change anything, so I just do my duty and move on.

I was put on a project a few years back that I thought was heading in the wrong direction. I said something and was ignored. I said something again and it was made clear by the response that the new VP had surrounded himself with yes-men and there was no more room for this kind of input. Ever since I have watched train wreck and train wreck. I’m not going to fight to help people who don’t what to listen to well meaning feedback.

Funny enough, 2 years after I was told to get on board or keep my mouth shut, customers complained about the very thing I said they would complain about. I felt slightly vindicated, and they had to rearchitect the whole thing to try and accomplish it. It’s been 5 years since the project started and they still haven’t fully shipped the feature.

It depends.

If you have the power (as the post mentions - like a CEO) you can suggest, direct or butcher a project and no one would see you as a negative person.

But you can get butchered when you don't have the authority to poke around your concerns.

I would prefer to see the ship sink instead of shooting myself in the foot and risking my influence and credibility - as another comment on this thread said "Sometimes, you have to let people fail".

I think this is the best take. If you know better speak up (assuming you don't get penalized for that). But anytime you feel the pain, refrain. Don't carry the weight of the world upon your shoulders. You spoke up and if they did not heed your advice that's not your problem.

How well has that worked? Has it backfired?

I think you both are right in different ways.

you can do your best to play it smart. perhaps following this direct advice isn't wise but something tweaked to your own understnading of it is likely the option. I agree with the post. a way id reword it is "don't get too deep into politics, take a step back instead and assess the trade-offs of being involved or not"

>If I see something heading toward failure, I let people know they may want to consider a different approach. That’s it. There’s no need to be harsh or belabor the point but it’s better to speak up than to quietly watch a train wreck unfold.

Yes, it seems cruel and also counter to ensuring the org succeeds. Your perceived ability as an engineer might go up if your colleagues fail, but your colleagues failing when you knew a possible way for things to go better is harmful to your org's goals and culture. It only takes a small few failures for the bar to be lowered to the point that you yourself may not want to work there.

Even sometimes when other people's projects are NOT your problem and they aren't seeking feedback, sometimes you SHOULD make their flaws your problem if it is of crucial importance to your org. Knowing when you should expend your energy on an initiative like that is in itself a mark of seniority.

The blog itself mentions this a bit.