Framework 06 · Movement II — Teams & systems
The kill rate
How much a team kills is one of the truest signals of its health, and almost nobody tracks it.
A team celebrates every launch and mourns every cancellation, so the roadmap only ever grows. Look up a year later and half of what shipped is quietly dead in the product, still costing money to keep alive, and no one remembers deciding to keep it.
Immature teams measure themselves by what they ship. Shipping feels like progress, and a cancelled project feels like admitting you were wrong, so every incentive points one direction: launch, defend, keep. Nothing ever leaves. The backlog only grows and the product accretes.
Mature teams kill more than they launch, and they do it on purpose. They know that saying no to a live project is harder and worth more than saying yes to a new one, because the live project already has champions, sunk cost, and a story. Killing it well takes more judgment than starting it did. A high kill rate is not carnage. It is a team that can tell the difference between motion and progress, and act on it before the dead weight compounds.
The kill rate is a health metric because it measures the one thing a launch count cannot: whether a team is willing to be wrong out loud. A team that never kills anything is not disciplined. It is afraid. And the cost of that fear does not show up as a failed launch. It shows up as a bloated product, a team spread thin across too many half-alive bets, and a roadmap nobody can explain.
A team that never kills anything is not disciplined. It is afraid.
What to do with it
Count what you killed this quarter, not just what you shipped. If the number is zero, that is the finding. Take the project with the most champions and the least evidence, and have the conversation about ending it while it is still small enough to end cleanly.
From idea to practice
This one runs as a team workshop, and it is part of the coaching.