Some Projects Need to Fail

The piece argues that repeatedly assigning top engineers to rescue failing projects can make an organization worse, even when each rescue succeeds. A strong engineer may untangle unfamiliar code, coordinate stakeholders, clarify ownership, and deliver what once seemed impossible. But that outcome can conceal why the project was in trouble and make rescue work seem like a normal part of planning. Meanwhile, the engineers are pulled away from other valuable work, spend time ramping up, and may inherit operational problems created by rushed compromises. The implicit reward for competence becomes being sent to fix someone else’s mess.

Leaders should decide whether to continue by comparing the likely business benefit of a rescue with its full cost, including the work displaced and the time needed for the engineer to become effective. Past investment is not, by itself, a reason to keep spending; if continuing cannot produce a better outcome than stopping, the project should be allowed to fail. A visible failure can expose flawed decisions, pressure, or organizational problems and prompt an honest discussion, while a successful rescue may let those causes go unexamined. Failure does not guarantee learning, but habitual heroics make learning less likely and encourage dependence on emergency intervention. Before calling in a star engineer, leaders should ask whether they are protecting the business or shielding the people - including themselves - whose choices created the crisis.