I have killed more projects than I have shipped. That is not a confession, it is a job description. If you run engineering for a payments company, most of your calendar is spent on things that will eventually be true, and a good chunk of your judgment is spent deciding which of them are worth continuing. The shipping is the fun part. The killing is the part nobody teaches you, and it is the part that separates a team that trusts you from a team that quietly stops telling you the truth.
The bad news is that a project rarely dies once. It dies in stages, usually badly, and the way you handle the death is remembered far longer than the launch that never happened. I want to talk about how to do it with some dignity, because I have done it clumsily enough times to know what the clumsy version costs.
The tell is that everyone already knows
Here is the thing about a project that needs to die: the team almost always figures it out before management does. Engineers are close to the ground. They can feel when the estimates keep sliding for reasons nobody can name, when the demo works only if you click in exactly the right order, when the third rewrite of the reconciliation logic still does not balance to the penny. They know. What they are waiting for is permission to say it out loud.
I once inherited a real-time fraud scoring engine that had been "two sprints from production" for fourteen months. Fourteen. The team had stopped believing in it around month five, but the original sponsor was a VP who had staked his reputation on the launch, so everyone kept nodding in standup and building features nobody trusted. The waste was not the fourteen months of salary, painful as that was. The waste was that four good engineers spent a year learning that honesty was not rewarded.
So the first skill in killing gracefully is not decisiveness. It is listening for the silence, the polite agreement that has replaced argument. When a team stops fighting about a project, they have not reached consensus. They have given up.
Write the obituary before the funeral
Before you announce anything, write down why the project is ending. On paper, in plain language, in a document you would be comfortable showing the people who worked on it. This forces a discipline that meetings do not: you have to distinguish between the project being a bad idea and the project being poorly executed, because those two deaths require very different eulogies.
A bad idea is not the team's fault. Maybe the market moved, maybe a partner pulled out, maybe the regulation you were betting against went the other way. Poor execution is a harder conversation, and you owe it to everyone to be honest about which one you are dealing with. Mixing them up is how you either scapegoat a team that did fine work on a doomed premise, or let a genuinely troubled team believe they were unlucky when they were undisciplined.
The obituary also protects you from the most dangerous outcome, which is killing the right project for the wrong reason and then repeating the mistake six months later with a different name on it.
Sunk cost is a feeling, not an argument
Every doomed project has a defender whose central argument is the amount of money already spent. "We have put eight hundred thousand into this, we cannot just stop." I understand the instinct. I feel it too. But the money is gone whether you continue or not, and the only real question is whether the next dollar is better spent finishing this thing or doing something else.
The version of this that actually works in a room full of executives is to reframe it as a fresh decision. Pretend the project does not exist. Someone walks in today and pitches it, with the current state of the codebase, the current team morale, the current market. Would you fund it? If the answer is no, then the eight hundred thousand is not a reason to continue. It is tuition. You already paid it. The question is whether you want to keep paying.
The most expensive project is not the one you kill. It is the one you keep half-alive because nobody wants to be the person who said stop.
I have watched companies spend two years and several million dollars keeping a project on life support because a single quarter of honesty felt more expensive than years of quiet bleeding. It never is.
Tell the people who built it before you tell the org
This one is not negotiable for me, and I have gotten it wrong in a way I still think about. Early in my career I let a project cancellation get announced in an all-hands before I had spoken to the two engineers who had poured a year into it. They found out at the same time as the sales team. One of them left within a month, and he was right to.
The order matters more than the words. The people closest to the work deserve to hear it from you, in a room or on a call, before it becomes company gossip. Give them the real reasons, not the sanitized version you will use in the newsletter. They earned that. And they will smell a sanitized version instantly, which just teaches them that you manage them with press releases.
When you do tell them, resist the urge to soften it into meaninglessness. "We're pausing to reassess strategic alignment" fools no one and insults everyone. Say the project is ending, say why, and then shut up and let them react. Their anger, if there is any, is not an attack on you. It is grief for work they cared about, and the worst thing you can do is treat it as insubordination.
Salvage the parts worth keeping
A dead project is rarely a total loss, and finding the survivors is both good engineering and good therapy for the team. The fraud engine I mentioned was a failure as a product. But the feature store the team built to feed it was excellent, and it went on to power three other services that shipped without drama. Naming that survivor in the same conversation where you announce the death changes the emotional register from "your year was wasted" to "your year produced something we are keeping."
When I run a project post-mortem, I make the team list what is worth carrying forward. It usually falls into a few buckets:
- Code and infrastructure that other teams can adopt with minor changes
- Hard-won domain knowledge, especially about regulatory edge cases, that needs to be written down before it walks out the door
- Tooling and test harnesses built along the way that are useful regardless of the product
- The clear, documented understanding of why this approach does not work, which is worth more than people admit
That last one is underrated. A well-documented dead end saves the next team from wandering into it. In a regulated domain, knowing precisely why a settlement approach fails compliance review is genuinely valuable institutional memory, not a footnote.
There is a right way to actually turn it off
Killing a project is not just an announcement, it is an operational task, and in fintech it is one you cannot fumble. If the project touched real money movement, customer data, or a live integration, "we stopped working on it" is not the same as "it is safely shut down." I have seen a cancelled pilot keep pulling from a partner API for eight months after everyone believed it was dead, quietly running up cost and, worse, holding a data-sharing agreement open that legal thought had closed.
So the wind-down needs an owner and a checklist. Decommission the credentials. Revoke the API keys. Archive the data according to your retention policy rather than letting it rot in a bucket nobody remembers. Update the architecture diagrams so the next engineer does not build on a foundation that no longer exists. This is unglamorous work, and it is exactly the kind of thing that gets skipped because the project is "over" emotionally before it is over technically.
Give the wind-down a real deadline and a named person. A project that is "being wound down" indefinitely is not dead. It is a zombie, and zombies eat attention.
Protect the people, not the plan
The single biggest fear when a project dies is not embarrassment. It is that the people attached to it will be seen as tainted. If your engineers believe that being on a cancelled project is a career risk, they will fight to keep dead projects alive out of pure self-preservation, and you will have built a machine that structurally resists honesty.
The fix is to make it explicit, repeatedly, that the decision to stop reflects on the idea and the circumstances, not on them. Then back it with actions. Put the strong engineers from the dead project onto the most visible thing you have going. Say publicly that the fraud engine team is the reason the new feature store shipped clean. When people see that a cancelled project did not damage anyone's standing, they stop protecting doomed work.
There is a real tension here, and I will not pretend otherwise. Sometimes a project fails partly because of the team, and protecting people cannot mean pretending no one is accountable. But accountability is a private, specific conversation about performance. It is not a public verdict delivered by cancelling a project. Confusing the two poisons both.
Faster than comfortable, slower than reckless
The hardest part is timing, and I do not have a formula. Kill too early and you strangle something that just needed one more pivot. Kill too late and you have burned a year teaching your best people that leadership cannot make a call. I lean toward earlier than my gut wants, because I have far more regret about the fourteen-month zombie than about anything I stopped too soon.
What helps is setting the exit conditions before you are emotional about them. When we start something genuinely risky now, I ask the team to write down what would have to be true by a specific date for us to continue, and what result would mean we stop. Not vague vibes. A number, a milestone, a yes-or-no test. When that date arrives, the decision is half made already, because we agreed on the rules back when nobody's ego was on the line.
It does not remove the pain. But it turns "you gave up on my project" into "we hit the line we drew together," and that difference is the whole game.
How you end things is the interview
The reflex is to treat a killed project as a failure to hide, a line item to bury in a reorg. I have come to think the opposite. How a leader ends things is the clearest signal a team gets about whether honesty is safe here. Ship a product and you prove you can execute. Kill one well and you prove that people can tell you the truth without it costing them, which is the only thing that lets you find out early next time. The graceful death is not a consolation prize. It is the practice that makes the next hard call cheaper, faster, and a little less lonely.