I once spent eight months building a dashboard that nobody asked for. The stakeholder had nodded along during the kickoff. The engineers had agreed the API was doable. The budget was approved. We shipped it on time, under budget, and with zero critical bugs. It was a masterpiece of execution, and within six weeks it had exactly three active users. Two of them were on my team. The third was the stakeholder’s assistant, who opened it once by mistake.
That was the year I learned that the most valuable project meeting isn’t the kickoff, the sprint review, or the post-mortem. It’s the one where you look at an idea—one that is already funded, already staffed, already beloved by someone with a title—and you say, out loud, in a room full of people who want to please that someone: “What if we just didn’t?”
Most of our calendars are stuffed with meetings designed to move things forward. Status updates, prioritization huddles, roadmap grooming. But the meeting that saves real money, real time, and real sanity is the one engineered to stop something in its tracks. It’s not a “no” meeting. It’s a decision meeting with a very specific agenda: confirm whether this thing should continue to exist. And if you don’t hold it on purpose, it will happen anyway, usually at 4:30 p.m. on a Thursday when a lead engineer says, “Guys, are we sure about this?” and everybody stares at the screen and feels sick.
Why Nobody Schedules the “Let’s Not” Meeting
Organisations are wired for yes. A new project means a new budget line, a new team, a new slide in the quarterly review. There’s a subtle career incentive to be the person who launches things, not the person who kills them. A VP with five active initiatives looks ambitious. A VP who shut down two of them looks, at least temporarily, like someone who made a mistake.
But the real reason we avoid the cancellation conversation is simpler: it feels rude. A project has a sponsor, and that sponsor has hopes, and those hopes have been translated into a Gantt chart with colours. Telling someone their baby is ugly is hard. So we defer. We say “let’s just see how the pilot goes” while knowing the pilot will cost $200,000 and lock in three engineers for a quarter. We wait for the market to prove us right, even though the market already shifted while we were writing the business case.
I’ve been in rooms where the data screamed “stop” and we still added a Phase 2. The logic was always some variation of “we’ve already invested so much.” That sunk-cost whisper is the most expensive sound in tech. It’s the reason a prototype becomes a product, a product becomes a platform, and a platform becomes a full-time team of twelve maintaining something that generates less value than the coffee budget.
What a Proper “Don’t Do It” Meeting Looks Like
This isn’t a brainstorming session. It’s not a retrospective. It’s a structured, time-boxed interrogation with exactly one possible outcome: we either recommit with clear eyes, or we pull the plug before the next billing cycle. Here’s how I set it up now, after the dashboard incident and a few other expensive near-misses.
1. Invite the right people, and only the right people
The sponsor must be there. The lead engineer or architect. One person who understands the actual user problem (if there is one). And someone with budget authority who is not emotionally attached—often a finance partner or a senior director from a different area. Do not invite the whole working group. Do not make it a “general update.” This is a decision meeting, and decision meetings die when the room is too polite.
I once invited a junior designer to a kill meeting because “she’d worked hard on the wireframes.” She spent twenty minutes defending colour choices while the rest of us tried to discuss whether the feature solved a problem that still existed. Never again. The meeting isn’t a performance review; it’s a verdict on the work, not the people.
2. Start with the original bet, not the current state
Most project reviews begin with a progress report. “We’re 60% done, QA starts next week, the API latency is down to 200ms.” That’s a trap. It frames the conversation around momentum, and momentum is hard to argue with. Instead, start by restating the bet you made when the project was approved. What did you believe would be true by now? More users, lower costs, faster onboarding? Write that on the board before anyone speaks.
I keep a one-page document for every project I oversee, and the top section is simply “What we said would happen by [date].” If we can’t remember what that was, the project is already in trouble. If we can remember, and it’s painfully obvious it didn’t happen, the conversation gets honest fast.
3. Ask the three questions that matter
I borrowed these from a product director who had killed more features than I’d ever launched, and she delivered them with the calm of someone ordering a sandwich.
Question 1: If we stopped today, who would genuinely notice, and how long would it take them to complain? Not “who likes the idea.” Who would be blocked. If the answer is “nobody for at least a month,” that’s a signal.
Question 2: What new information would make us kill this project instantly? If you can’t name a specific trigger—a competitor launch, a regulatory change, a user metric dropping below a threshold—then you’re not managing a project; you’re riding a hope.
Question 3: Is the team still the right team for this problem? Sometimes the project is valid but the people are burned out or misaligned. Admitting that is cheaper than pretending morale will recover on its own.
4. Document the decision like a contract
If you decide to continue, write down exactly what must be true in 30 days to keep going. No vague “revisit in Q2.” A hard checkpoint with a named owner. If you decide to stop, write the shutdown plan in the same meeting. Servers to spin down, redirects to put in place, people to reassign, stakeholders to notify. A clean stop is a skill, and it’s one that builds trust. People remember that you didn’t just disappear the project; you tidied up after it.
The Real Cost of Avoiding the Conversation
I’ve tracked this informally across three companies, and the pattern is consistent. A project that should have been killed at month three but survives to month nine will consume roughly 20-30% more than its original budget, not because it grew, but because teams slow down. People sense a zombie project. They deprioritise it without saying so. Meetings get rescheduled. The QA environment rots. And all the while, the engineers on that project aren’t available for something sharper.
That’s the hidden tax. It’s not just the money spent; it’s the opportunity cost of tying up your best people on something they don’t believe in. I’ve watched a senior backend engineer spend six months building a microservice for a feature that was eventually shelved. He left three weeks after the cancellation. Not because he was angry, but because he’d been bored for half a year and nobody had noticed.
There’s also a credibility cost. When your team sees you consistently launch and maintain things that don’t matter, they stop trusting the roadmap. They start treating every new initiative as temporary, because experience has taught them that 40% of them are. That cynicism is hard to reverse. But when you demonstrate that you can kill a project cleanly and redeploy the team to something sharper, you earn a different kind of respect. People start treating the roadmap as a set of real commitments, not a wish list.
How to Pitch This to Your Organisation
If your company doesn’t have a culture of stopping things, don’t start with the word “kill.” Start with “recommit.” Frame the meeting as a “Project Health Check” or a “Go/No-Go Review.” The agenda is the same, but the label matters. Some executives need to feel they are choosing to continue, not choosing to stop.
I once worked with a CFO who refused to cancel a project because “it’s already in the forecast.” So we reframed the decision. We weren’t cancelling; we were reallocating the remaining budget to a higher-return initiative that had just passed its own health check. Same financial impact, different story. The project ended, the team moved, and the forecast got an amendment instead of a scar.
Another tactic: run a pre-mortem at the start of every project. Before you write a single line of code, gather the team and say, “Imagine it’s twelve months from now and this project failed. Write down why.” Collect the answers, seal them in a shared document, and revisit them at the first health check. You’ll be stunned how often the pre-mortem accurately predicts the real failure mode. And when it does, the decision to stop feels less like an admission of failure and more like the team was smart enough to see it coming.
The Emotional Side Nobody Talks About
Stopping a project hurts. It hurts the sponsor who championed it. It hurts the engineer who stayed late to fix a gnarly integration. It hurts the junior PM who put it on their resume draft. Ignoring that pain doesn’t make it go away; it just makes the meeting awkward and defensive.
I’ve learned to name the emotion early. Something like: “I know a lot of work has gone into this, and I’m not dismissing that. We’re here because the situation changed, not because anyone did bad work.” It sounds like management cliché, but it actually works if you mean it. And you should mean it. Most projects that need to be killed were started for good reasons by smart people. The world just shifted underneath them.
After a cancellation, I always follow up individually with the people most affected. A five-minute call to say “that was a tough call, but it was the right call, and here’s what I’d like you to do next” goes a long way. People want to know their effort wasn’t wasted, even if the output was. The learning usually wasn’t wasted: a new integration pattern, a better understanding of a user segment, a reusable component. Name those things. Make them visible. It turns a loss into a deposit in the team’s collective skill account.
When You Should Absolutely Not Cancel
This isn’t an argument for killing everything that wobbles. Some projects need to look ugly at the midpoint. Platform migrations, compliance work, long-cycle hardware integrations—these often have a valley of despair where the only sensible thing is to keep going. The difference is that those projects usually have a non-negotiable external driver. A regulatory deadline. A contract obligation. A physical supply chain that’s already in motion.
The projects that benefit from a hard “let’s not” review are the ones driven by internal ambition: a new feature, a new product line, a “strategic initiative” that sounded great in a Q1 planning session but hasn’t touched reality since. If the primary reason it exists is “we decided to do it,” then you should be able to decide to un-do it.
Building the Habit
At this point in my career, I schedule a formal “Continue/Stop” checkpoint for every project longer than six weeks. It’s a recurring 45-minute slot, always on a Wednesday (nobody has energy for this on a Monday, and Friday decisions are forgotten by Monday morning). The first one happens at the 30% completion mark, because that’s when the initial excitement has worn off and the real complexity has surfaced. The second one happens at 70%, when you’ve got enough data to know if the bet is paying off.
Does this feel bureaucratic? A little. But it’s far less bureaucratic than maintaining a project that should have died months ago. That’s the real red tape: the status reports nobody reads, the standups where nobody has updates, the roadmap item that keeps sliding to the right while everyone pretends it’s still important.
The best engineering cultures I’ve been part of had one thing in common: they celebrated good stops. When a team killed their own project and clearly articulated why, the leadership response was “thank you for saving us from ourselves.” That’s a hard norm to build, but it starts with one meeting where someone says, “I think we should stop,” and the room doesn’t flinch.
Frequently Asked Questions
How do you avoid demoralising the team when you cancel their project?
Separate the decision from the people. Explicitly recognise the effort and skill that went into the work, and identify specific learnings or reusable outputs. Then move people to a new assignment quickly—within a week if possible. The fastest way to rebuild morale is to give them something real to work on, not a “reflection period.”
What if the sponsor won’t let the project die?
Shift the conversation from “stop” to “compare.” Ask the sponsor to rank this project against the other things their team is doing. If it’s genuinely the lowest priority, frame the cancellation as freeing up capacity for higher priorities. If the sponsor insists everything is equally important, you have a different problem entirely—one that a project health check won’t solve.
How often should these cancellation meetings happen?
For projects longer than six weeks, schedule them at roughly the 30% and 70% completion points. For shorter projects, a single checkpoint at the midpoint is usually enough. The key is to put them on the calendar at the start, so they feel like a normal part of the project rhythm, not a panic response.
What’s the smallest sign that a project should be stopped?
When the team can’t explain, in one sentence, who this helps and why it matters right now. Not who it might help later. Not who it would help if the market shifted. Right now. If that sentence takes more than ten seconds to say, the project is running on inertia.
The meeting where you decide not to do something isn’t a failure. It’s a discipline. And like any discipline, it feels unnatural until you’ve done it a few times. After that, it feels like one of the few adult moments in a calendar full of wishful thinking.