Obviously you have some things in mind, which I won't be able to understand entirely, but for the sake of argument let's look at your example. If you have a large contract built on fragile tech with no design and no care, then in order to save the project (from a technical perspective) my experience is that you often have to step on some toes. Code doesn't get that way by accident. Somebody (very likely everybody) thought that they were doing the right thing. Explaining that they were wrong is a horrible job (I hope you get paid a lot ;-) ).

But if you think back, how many times did people thank you (before the end of the project) for doing what was necessary to get the project back on track? How many times did you use super human effort to claw a monstrocity from the brink of disaster and have half the dev team pissed off at you because of it.

I don't want to get into a large discourse, but your posting stood out a bit, in a "I know that pain" kind of way. I don't know you so this may be totally wrong, but my experience has been that there are many roads to success. Even that word "success" is arbitrary (as we have seen so frequently when managers redefine it after the fact). You are allowed to choose your definition.

Sometimes you just aren't up for the gunslinging heroics that are required save the project. But you might be up for spending some quality time with the other developers and helping them improve themselves. The project may tank, but everybody might end up thanking you because of it. Even better, you may inspire someone else to do the necessary heroics now that they have someone to cheer them on.

The one (somewhat disturbing) reality that I have learned in this job is that neither my pay check, nor the way people feel about me seems particularly related to the success of any particular project. Sometimes giving people what they should value (success) over what they actually value (support) is a form of hubris in itself.

Anyway, I hope that is interesting even if it doesn't seem useful ;-)