You wrote the kill criterion before the pilot began, the criterion has fired, and now you have to walk into a room full of people who poured three months into a workflow they believe in and tell them it is over. They will not agree. They will see promise around the next corner, and they will be partly right, because they always are. The way you run this conversation determines whether your design org ever takes another risk - because every IC in the building is watching to learn what happens to people whose experiment gets killed. Do it wrong and you teach the team that pilots are career risks to be avoided. Do it right and you teach them that taking a smart, well-bounded bet and having it not pan out is a normal, safe, even respected part of an AI-native design practice. This lesson scripts the shutdown, separates the project's failure from the team's worth with surgical care, and hands you a postmortem template that turns a dead pilot into reusable organizational learning.

Why the Shutdown Is the Real Leadership Test

Starting pilots is easy and feels good; everyone enjoys the optimism of a kickoff. Killing them is hard and feels bad, which is exactly why how a leader handles the kill reveals more than how they handle the launch. The shutdown is where your stated values about psychological safety, intelligent risk-taking, and learning culture get tested against reality, and the team knows it. They are not really listening to whether you have a learning culture in the all-hands; they are watching what happens to the three people whose pilot just got killed. That observation, repeated across a few cycles, becomes the actual culture, regardless of what the values deck says.

The stakes are concrete. If killing a pilot is experienced as blame - if the people who ran it come out diminished, sidelined, or quietly distrusted - then every rational designer in your org learns to avoid pilots, or to run them so conservatively that they cannot fail, which defeats the entire purpose of having a pilot portfolio. You will have optimized your team for the appearance of innovation while killing the substance. Conversely, if killing a pilot is experienced as the clean, respected conclusion of a smart bet, designers learn that the downside of an experiment is bounded and survivable, and they take the kinds of risks that actually move the practice forward. The shutdown conversation is where you either build or destroy your org's appetite for the bets it needs.

There is a personal dimension for you too. If you championed the pilot, killing it requires admitting a bet you made did not pay off, in front of the people who trusted your judgment. The temptation is to distance yourself - to let the failure attach to the team rather than the decision - and it is a temptation you must refuse completely, because the team will see it instantly and it is the single most corrosive thing a leader can do. Owning the bet as yours is the foundation everything else in the shutdown rests on.

The Core Move: Separate the Project from the People

The entire craft of a humane shutdown reduces to one move performed relentlessly: separate the project's failure from the team's worth, and never let the two touch. The project failed. The people did exactly what you asked - they ran a well-bounded experiment competently, the experiment resolved against the hypothesis, and resolving a hypothesis is success at the level that matters, even when the hypothesis turned out false. A pilot that runs cleanly and produces a clear negative result is a successful pilot. The team did their job. The project did not work. These are different sentences about different things, and the leader's job is to hold them apart so completely that no one in the room can blur them.

This separation is hard precisely because the team will try to blur it themselves, out of ownership and identity. They built the thing; its failure feels like their failure. Your job is to refuse their self-blame as firmly as you refuse any external blame: "You ran this exactly right. The kill criterion fired because the technology is not ready for this use case yet, not because you executed poorly. We learned the frontier is two quarters out, and we learned it cheaply and cleanly, which is exactly what this pilot was for." You are not consoling them; you are correcting a factual error about what happened. They are misattributing a project outcome to personal failure, and you are setting the attribution straight.

Naming the Failure Type Does the Emotional Work

This is where the pre-written kill criterion pays off enormously. Because you named the failure type in advance - technology not ready, use case wrong, or adoption broke down - the shutdown conversation has a ready-made, non-personal explanation for what happened. "The kill criterion we agreed to in March said: if zero agent proposals pass clean review by week eight, the frontier is not here yet. That is what happened. The failure type is technology-not-ready, which we anticipated as a real possibility when we scoped this as the bet." Naming the failure type as a category you predicted converts the kill from a judgment about the team into the firing of a tripwire everyone agreed to. The team did not fail; a pre-agreed condition was met. That reframe is most of the emotional work, and it is only available to you because you wrote the criterion before anyone was attached.

Scripting the Conversation

Do not improvise this conversation. Script it, because under the emotional pressure of disappointing people you respect, you will reach for whatever language is easiest, and the easy language is often the language that blames. A scripted shutdown moves through five beats, in order, and the order matters.

Beat one: own the decision and the bet. Open by taking ownership: "I made the call to run this pilot, and I am making the call to stop it. That is on me, not on you." This puts the decision's weight on the leader and signals from the first sentence that nobody is being scapegoated. Lead with ownership before anything else, because everything after it is heard differently once the team knows the failure is not being routed to them.

Beat two: state the kill criterion that fired. Be factual and specific: name the criterion you all agreed to, show that it fired, and name the failure type you predicted. This is the non-personal anchor. It moves the conversation from "is this fair" to "the condition we agreed on was met," which is a much safer place to stand.

Beat three: separate the project from the people, explicitly and by name. Say it directly: "This project did not work. You did. You ran a clean experiment and produced a clear result, which is exactly what I needed from you." Do not let this be implied; say the sentence out loud, because the team needs to hear the separation in words, not infer it from tone.

Beat four: name what was learned and where it goes. A kill with no learning is a waste; a kill with documented learning is an investment that paid off in information. Tell them specifically what the org now knows that it did not before, and that the learning will be captured and carried forward - so their three months produced durable value even though the workflow itself is being retired. This is what makes a kill feel like a contribution rather than a loss.

Beat five: name what is next for the people. The team will be anxious about what happens to them now. Answer it before they ask: here is the work you are moving to, here is how this pilot counts in your favor (you took a smart risk and executed it well), here is that this does not follow you. Ending on the people's future, not the project's past, is what sends them out of the room intact.

A pilot that runs cleanly and produces a clear negative result is a successful pilot. The project failed; the people did exactly what you asked. Hold those two sentences so far apart that no one in the room can blur them - including the team trying to blame themselves.

Handling the Team That Wants to Keep Going

The hardest version of this conversation is the one where the team genuinely believes the pilot is about to work and wants to push past the kill criterion. They are not being unreasonable; they are experiencing the sunk-cost and optimism that the pre-written kill criterion exists precisely to override. Your move here is delicate, because you must honor their judgment without surrendering the discipline that makes the portfolio work.

Start by taking their belief seriously rather than dismissing it: "You may be right that it is close. I respect that you see promise, and you have earned the right to that view by living in this for three months." Then return to the discipline: "And the reason we wrote the kill criterion in March, before any of us was attached, is that everyone who has ever run a pilot sees promise around the next corner at exactly this point. That feeling is not evidence; it is the predictable experience of a team that has invested. We agreed in advance to let the pre-committed condition decide precisely so that this feeling would not." You are not telling them they are wrong about the promise. You are telling them that the feeling of promise is exactly what the kill criterion was designed to discount, and that honoring the pre-commitment is what lets the org keep running pilots at all.

If their evidence is genuinely new - if something material changed that the original kill criterion did not anticipate - then the disciplined response is not to ignore it but to re-scope: kill this pilot as designed, and if the new evidence is strong, charter a new pilot with a new hypothesis and a new kill criterion. This preserves both the discipline (the original criterion fired, the original pilot ended) and the openness (genuinely new information gets a fresh, bounded experiment rather than an indefinite extension of the old one). What you never do is extend the original pilot indefinitely on the strength of the team's optimism, because that is precisely the zombie-pilot failure the whole kill-criterion discipline exists to prevent.

The Postmortem Template

The artifact is a postmortem template, and its design encodes the entire blame-free philosophy into a reusable structure so that the next leader running a kill does not have to reinvent the humane version. The template has six sections, deliberately ordered to put learning and people ahead of fault.

What we believed (the hypothesis). Restate the original hypothesis and risk level. This frames the pilot as a bet that was made deliberately, not a project that was supposed to succeed - which immediately reduces the sense of failure, because bets are expected to sometimes lose.

What happened (the kill criterion that fired). State factually which criterion fired and when, with the data. This is the non-personal record of why the pilot ended, and it should read like a tripwire report, not a judgment.

Failure type. Name the category - technology not ready, use case wrong, adoption broke down - because the type determines what the org should do next (revisit later, never revisit, or fix adoption and retry). The failure type is the single most reusable piece of learning in the document.

What we learned. The substantive section: what does the org now know that it did not before? The frontier's location, a tool's real limits, a workflow's hidden verification cost. This is the return on the pilot, and a good postmortem makes it concrete enough that another team can act on it.

What we are doing with the learning. Where the knowledge goes - which decisions it informs, which future pilots it shapes, where it is documented. Learning that is not routed somewhere evaporates; this section ensures it does not.

The people. The section most postmortems omit and the one that protects the culture: an explicit statement that the team executed well, that the kill reflects the bet and not their performance, and where they are going next. Putting the people in the template, by name, ensures that no shutdown the org ever runs forgets to separate the project from the people - it is built into the form.

The template's quiet power is that it makes the humane shutdown the default. A leader who fills out this template cannot accidentally write a blame-laden postmortem, because the structure forces ownership of the bet, a non-personal account of the kill, and an explicit defense of the people. You are not just documenting one kill; you are encoding how every future kill should be done.

A Worked Example: Killing the Agentic-System Bet

Return to the bet from a pilot portfolio: the agentic design-system workflow where an MCP-enabled agent reads the tokens and proposes components, with a kill criterion of "zero clean-review passes by week eight means the frontier is not here yet." Week eight arrives; the agent's proposals are plausible but never quite system-compliant - close, drifting, never clean. The team of two has fallen in love with it and is sure that one more sprint of prompt-tuning will get there. The criterion has fired. You run the shutdown.

You open by owning the bet: this was your call to fund and your call to stop. You state the criterion factually - zero clean passes by week eight, the tripwire you all set in advance - and name the failure type as technology-not-ready, the category you flagged as likely when you scoped this as the bet. You separate the project from the people in plain words: the workflow is being retired; their execution was excellent and produced exactly the clean negative result the bet was for. When they push to keep going - "we are so close" - you honor the belief and return to the discipline: the feeling of being close is precisely what the criterion was written to discount, and if they have genuinely new evidence you will charter a fresh, bounded pilot rather than extend this one indefinitely. You name the learning: the org now knows agentic system-compliance is roughly two quarters out, knows exactly where the drift occurs, and is positioned to move first when the frontier closes - which is worth far more than the cost of the pilot. And you end on their future: both designers move to the stretching pilot, this counts as a smart risk well-run in their favor, and it follows them as a credit, not a mark. They leave the room disappointed about the workflow and intact as people, and the rest of the org learns that a killed pilot is survivable - which is the whole point.

Putting It to Work This Quarter

Before you ever have to kill a pilot, adopt the postmortem template and the five-beat script, because you will not invent the humane version under emotional pressure - you will reach for the easy language, and the easy language blames. Having the structure ready means that when a kill criterion fires, you run a process rather than improvise a disappointment, and the process is built to protect the people by default.

When the kill comes, own the bet first, anchor on the pre-agreed criterion and its failure type, say the separation between project and people out loud rather than implying it, route the learning somewhere durable, and end on the people's future. Watch what the rest of the org learns from how you handled it, because that lesson - not your values deck - is what determines whether your team ever takes another smart risk. The deliverable is not a tidy ending to one pilot; it is a reusable, blame-free shutdown practice that keeps your org's appetite for intelligent bets alive even as individual bets die, which is the only way a pilot portfolio works over time.

Key Takeaways

• The shutdown, not the launch, is the real leadership test. Every IC watches what happens to the people whose pilot got killed, and that observation becomes the actual culture - determining whether your org ever takes another smart risk regardless of what the values deck says.
• The core move is to separate the project's failure from the team's worth and never let them touch. A pilot that runs cleanly and produces a clear negative result is a successful pilot; the project failed, the people did exactly what you asked. Hold those sentences apart even against the team's own self-blame.
• The pre-written kill criterion does the emotional work: naming the failure type you predicted (technology not ready, use case wrong, adoption broke) converts the kill from a judgment about the team into the firing of a tripwire everyone agreed to before anyone was attached.
• Script the shutdown in five beats: own the decision and bet first, state the criterion that fired, separate project from people out loud, name what was learned and where it goes, and end on the people's future. Do not improvise - under pressure you reach for blaming language.
• For the team that wants to keep going: honor their belief, then return to the discipline - the feeling of being "close" is exactly what the kill criterion was designed to discount. If evidence is genuinely new, charter a fresh bounded pilot rather than extending the old one into a zombie.
• The postmortem template encodes the blame-free philosophy into six ordered sections (hypothesis, what happened, failure type, what we learned, where the learning goes, the people) so the humane shutdown becomes the default and no future kill forgets to defend the people who ran it.