Two years ago I killed a platform initiative that had been running for eight months. The team was sharp, the technical work was solid, and we were roughly six months from something shippable. I shut it down anyway, and I’ve thought about that decision often since.
What made it worth killing wasn’t that the work was bad. The problem we’d set out to solve had moved on us, and the opportunity cost of finishing had grown larger than the cost of stopping. That’s a hard calculation to make in a room where people have been giving a project their best work for the better part of a year. But it’s the right one.
Stopping good work feels like waste. Finishing the wrong work is the actual waste.
Saying yes to a project is costless in the moment. The room is energized, the team is ready, someone books a kick-off. The real cost doesn’t arrive until months later, as attention quietly drains away from everything else. Saying no has the opposite profile: the cost is immediate — a conversation, some disappointment, occasionally real pushback — while the benefit shows up slowly, as the things you kept actually get the resources they need to move.
This asymmetry is why organizations find it so hard to stop things they’ve already started. Bent Flyvbjerg spent decades studying infrastructure megaprojects and found the same pattern repeating across continents and project types: once the shovel goes in the ground, the project becomes too politically and psychologically expensive to stop, regardless of whether it should. He calls it the “break-fix cycle” — shallow planning followed by a quick start, then a long slow spiral of problems that were never examined before work began. Projects don’t go wrong, he writes. They start wrong.
Engineering teams have their own version of this. Technical work builds on itself, and stopping a build feels like waste in a way that’s hard to articulate to anyone who didn’t write the code. But that feeling is the sunk cost fallacy in a technical costume. The months spent are gone. The only question worth answering is whether continuing makes sense from here.
The harder discipline — the one that separates real strategy from a list of good intentions — is developing the diagnostic instinct before anything starts. Richard Rumelt’s framework for bad strategy is blunt about what most “strategies” actually are: statements of desire. Grow revenue. Improve the platform. Deepen the product. These name outcomes, not obstacles. A strategy, as Rumelt defines it, names the specific challenge, explains why it matters now, and points to a coherent set of actions concentrated enough to make a difference. If you can’t do that, you’re not ready to start the project. You have a wish, not a plan.
What I’ve built into our process: before we commit resources to anything significant, I ask the team to name what we’re betting against. Not what we’re building — what has to be true for this to matter, and what happens if it turns out not to be. Most projects that deserve to be killed can be identified this way before they start. Either the team can’t name the bet clearly, or they name it and find it thinner than they thought.
That process didn’t make the platform decision easier. It would have made it earlier. I forced the question after eight months that should have been asked at kick-off. The team was gracious about it. But the cost wasn’t just the eight months — it was what eight months of that team’s time, applied elsewhere, would have compounded into.
Rumelt’s most useful observation is this: most complex organizations don’t focus their resources. They pursue multiple goals at once and never achieve a breakthrough in any of them. The roadmap fills up. Teams spread across too many things. Every project gets some attention and nothing gets enough. This isn’t a failure of execution — it’s a failure of choice. Strategy, he argues, is at least as much about what you don’t do as what you do. That’s easy to agree with until you’re the person in the room saying no to something a team has been excited about for months.
What a consistent practice of killing projects signals to an organization is less obvious than it sounds. It’s not ruthlessness and it’s not indecision. What it signals is that the things that survive scrutiny are real — that when something gets a green light, it’s because someone thought hard about what it would take to matter, and believed it would. Teams move differently when they trust that. The alternative — a roadmap that exists because no one wanted the conversation — produces a specific kind of exhaustion where people work hard at things that never quite gain altitude.
The things that actually compound, in my experience, are almost always the result of refusing to add one more.
If you’re sitting on a decision about whether to start something or keep going on something you’ve already started — reach out. That’s usually the most consequential question on the table.
Richard Rumelt — Good Strategy Bad Strategy
Bent Flyvbjerg and Dan Gardner — How Big Things Get Done