If you want to save a project, assign your best engineer to the job. They will find a way out. They will contact the right people, dive deep into code paths they don't know, negotiate dependencies, bring clarity to who owns what and start executing on a hard path. They will eventually deliver what looked impossible a month ago. In the end, your engineer gets recognition and everyone moves on.
Later in the year, you encounter yet another project in desperate need of rescuing. You feel hesitant to intervene and ask your rockstar to chime in. You know they'll pull it off again. That's not the problem. The question is whether it's worth saving at all
Some Projects Are Better Off Failing
Failures Are Worth Having
When you think a brittle project won't make it, perhaps you should save yourself from investing more into a sinking ship. Because you already spent six months on it, you end up investing another three because you have people who can save it. Yes, it does work, but why would you do that?
You reallocated your two best engineers to a project that perhaps should have failed. You disrupted their ongoing work, which is probably important as well. Because you rescued the project, you may have also inherited new operational problems from the compromises you made during the rescue. Worse, you teach your best people that the reward for competence is getting dropped into someone else's mess.
Execs won't care anymore because the project is delivered. What happened during that delivery disappears along with the lessons. Why was it failing in the first place? People problems, poor judgement, timeline pressure? Whatever the reason, by intervening, you may have lost the opportunity to understand it and sent the wrong signal to everyone. If the cost of a rescue stays under the rug, there will be almost no reason to question the decisions that made it necessary. The project gets marked as delivered when in reality it should have been stopped. If you repeat that nonsense a few times, heroics inadvertently become the operating routine. Ultimately, your planning becomes secondary because you deal with "known" emergencies.
Knowing When To Let Go
So, do we not rescue projects at all? I think we need to go back to the sunk cost fallacy. We keep it simple and ask whether continuing can realistically produce a better outcome than letting something fail. Do we gain a better business outcome by pulling in our best engineer or not? Their time comes at a cost twice over. First, the work they stop doing, and second, the time spent ramping up before they can even help. If the expected benefit justifies those costs, then fair enough. You gotta do what you gotta do.
If the economics no longer make sense, the project should fail. Leadership should get the right signal. Some projects should simply make enough noise to show that not everything is possible at the expense of the people doing the work. A visible failure at least opens an honest dialogue instead of incentivizing heroics.
Failing a project won't guarantee anyone learns from it, but rescuing it guarantees nobody will even try. When you're about to pull your best engineer card, stop for a moment and ask. Are you actually protecting the business outcome, or the people who made the bad call including yourself?