Politically Dead Projects

Projects die politically months before they die officially. Learn to read the death certificate before it's signed — and leave before the stampede.

The zombie phase

Projects at big companies rarely get killed cleanly. Almost none of them receive the honest email: "We've decided this isn't worth it, wind it down." Instead they enter a zombie phase: officially alive, actually dead. The roadmap page still exists. Sprints still happen. Standups still happen. But somewhere above you, leadership has privately deprioritized the project, and nobody has sent the email — because nobody has to.

This is where engineers get hurt. Engineers are trained to finish what they start. Half-done work feels like a personal failure, so the instinct is to put your head down and push the thing to completion. That instinct is exactly wrong here, because completion is no longer possible — not because of technical difficulty, but because the organization has already withdrawn the political oxygen the project needs to ship, launch, and count. The political death happened months ago. You're just the last to be notified, and you'll be notified in the least useful way possible: at the official kill, alongside everyone else, when it's too late to exit gracefully.

The core skill is learning to detect the political death while the project still looks alive.

Death signs

None of these is conclusive alone. Two or three together is a diagnosis.

• The executive sponsor stops showing up. They used to attend your reviews; now they send a delegate, or nobody. Worse: the sponsor leaves or gets reorged, and no replacement sponsor steps up. An unsponsored project is an unowned liability.
• Headcount asks get deferred, not denied. "Next cycle" is the organizational equivalent of "let's stay friends." A live project gets its asks fought over. A dead one gets polite postponement, because denial would force an honest conversation.
• Your project vanishes from leadership's own story. Watch what your VP says at all-hands, what's in the org's planning docs, what gets cited in the upward narrative. Leaders promote the work they're betting on. If your project isn't in your VP's story, it isn't real — no matter what your roadmap says.
• Dependent teams quietly deprioritize their integration work. They heard the signal before you did, through their own leadership. When the API team slips your integration two quarters "due to competing priorities," they're telling you what their VP thinks of your project.
• Recruiting and transfers into the team freeze. Orgs don't pour new people into things they've privately written off. A hiring freeze scoped to your team is a message.
• The questions change tense. "When does it ship?" is a question about a living thing. "What have we learned?" is an autopsy question. When leadership starts asking for learnings, retrospectives, and "what we'd do differently," they are pre-writing the eulogy.

Why nobody announces it

The silence isn't an accident; it's the cheapest option for everyone above you.

Killing a project publicly costs the sponsor face — they championed it, argued for its funding, put it in their own promo narrative. A public kill is a public admission. It also forces immediate messy work: reassigning people, unwinding commitments to partner teams, explaining the decision upward. Starvation avoids all of that. Defer the headcount, stop mentioning it, let the sponsor drift away, and in three or four quarters the project dies of "natural causes" — attrition, missed milestones, a reorg that absorbs the remnants. Nobody had to be the executioner. Orgs prefer starvation to execution because starvation has no fingerprints.

There's a second failure happening at your level: the loyalty misfire. Engineers conflate leaving a doomed project with abandoning their teammates or betraying their manager. But run the actual mechanics: your staying does not change the project's political status. The decision was made above you, without you, and your continued effort is not an input to it. Staying doesn't save the project — it just spends your years. This is sunk-cost fallacy wearing the costume of duty.

The career math

Time on a politically dead project produces approximately nothing that the system can see. No launch, because it will never ship. No impact statements, because impact requires the work to land and be counted (see The Last Ten Percent — on a dead project there is no last 10% to land, because landing requires organizational reception, and the receivers have left the building). No sponsor attention, because the sponsors have already moved their attention to the things in their current narrative.

At review time, "spent three quarters building X, which was cancelled" reads as zero regardless of how good the engineering was. That's unfair to the engineering and completely accurate about the outcome. The org pays for outcomes it can see.

Moves

• Run the death-signs checklist quarterly, on your own project, honestly. The hard part is honesty — you're motivated to see life. Score each sign yes/no. Two or more yeses means treat the project as dying until proven otherwise.
• Ask your skip-level directly: "Where does this project fit in the org's top three priorities?" A crisp answer ("it's number two, here's why") is life. A vague answer — "it's important," "we're still evaluating," a pivot to what you've learned — is data. Vagueness from someone who knows the real priority list is the answer. (See Skip-Level Relationships — this is exactly what that channel is for.)
• If it's dead, negotiate your exit before the official kill. Go to your manager with a constructive frame: "I want to move toward X, which is on the critical path" (see Be on the Critical Path). Do this while you're a voluntary transfer, not a refugee. The official kill triggers a stampede — five engineers hitting the internal transfer list the same week, all with the same cancelled project on their record. Early movers pick their destination; late movers get placed.
• If you stay, own the wind-down visibly. A well-run sunset is real, legible work: migrating dependents off, archiving cleanly, writing the postmortem leadership actually reads, freeing the headcount gracefully. "Led the wind-down of X, unblocking two teams and recovering N engineer-quarters" is a genuine impact statement. Zombie maintenance is not — but a competent execution of the death is.

Diagnostic test

If your project shipped a milestone tomorrow, would anyone above your manager change their plans because of it — and if the honest answer is no, you're maintaining a corpse.