What You’ll Find This Week

In a Duke University study, senior managers worked through a business case in which a product they'd chosen to launch was failing two years in. Even after an analyst showed them the company would come out ahead by killing the product instead of keeping it on the market, only 6 of 28 killed it. Managers handed the same analysis who hadn't made the decision to launch, and had no promotion riding on the product, killed it 17 times out of 31.

Companies kill ideas on sight. But once someone's career is attached to a project, nobody is willing to pull the trigger.

This week: why the people who launch a project are the last ones who'll end it, why the sunk cost fallacy explains only part of that, and what X, Alphabet's moonshot lab, does differently.

Don’t Miss Our Latest Podcast

This Week’s Article

In 2016, Astro Teller, who runs X, Alphabet's lab for long-shot technology projects (formerly Google X but NOT formerly “Twitter”), told a TED audience how X treats a team that shuts down its own project. "They get applause from their peers, hugs and high-fives from their manager, me in particular," he said. "They get promoted for it." He added that X has "bonused every single person on teams that ended their projects, from teams as small as two to teams of more than 30."

The first time Teller stood one of those teams on stage and told the company they'd done more for innovation at X by ending their project than anyone sitting in the audience, he told NPR, "There was, like, an uncomfortable silence."

Most companies would understand the silence. Last year I wrote that the hardest call in corporate innovation is shutting down a business unit that still makes money. Ending a new project that isn't working should be easy by comparison, since it has no revenue for anyone to defend. Yet companies rarely kill those projects, because the person deciding whether to kill one is usually the person who launched it, and that person's career is riding on it.

Clayton Christensen argued in The Innovator's Dilemma that established companies are, if anything, too good at killing ideas. "The highest performing companies…have well-developed systems for killing ideas that their customers don't want," he wrote. Those systems keep a company focused on the customers who pay its bills today, and the same systems are how it gets disrupted. It kills the product its best customers haven't asked for yet, and a competitor builds it.

In a study published in 2005, researchers Donna Kelley, Heidi Neck, Gina Colarelli O'Connor and Albert Paulson interviewed managers at ten large US multinationals, with annual sales from just under $1 billion to just over $130 billion, about how each one managed radical innovation. They found that "any attention paid to killing ideas focused on weeding them out in the initial screening." The researchers noted that screening "carried the risk of rejecting good prospects when they were most vulnerable," before those prospects "had a chance to reveal their potential."

Screening is the cheapest place to kill an idea, because nobody has been hired to work on it yet and nobody's career depends on it. It's also where a company knows the least about whether the idea would work.

Kelley and her coauthors found the opposite problem once an idea got through screening. Projects that cleared screening and then later stopped looking promising "received no further funding and were left to languish, nonetheless consuming time and resources at a low level." As one manager in the study put it, "Many people will say, one of the main reasons we're not very good at new things is because we will not kill anything."

None of the ten companies had a clear process for ending projects, and the researchers traced the problem to two missing pieces that were both about what happens to the people involved: "a mechanism for recycling people once projects have disbanded or a reward system for killing projects." Without either one, a team had every reason to keep its project alive. One company wanted its project teams to say when a project was going nowhere, and the teams let projects "drag on because people were afraid of losing their jobs."

Once a team is attached to a project, ending it means deciding what happens to the people on that team. In the companies Kelley and her coauthors studied, nobody owned that decision, so projects kept tying up people and time long after the funding stopped.

In 1997, three Duke University researchers, William Boulding, Ruskin Morgan and Richard Staelin, published an experiment run on 209 senior managers from Duke's executive programs, who averaged about 14 years of management experience. Each manager worked through a business case about launching a new industrial valve. The researchers told most of them that if they launched the product and it succeeded, they'd likely be on the fast track to senior management, and that passing on the launch wouldn't hurt their careers. The authors built that setup to mimic "a typical organization's reward structure."

Two years into the case, the product was failing. Market share came in at 24% against an expected 35%, because of a production problem the case described as uncorrectable. The managers who had launched the product were then asked whether to keep it on the market or kill it. In the basic version of the case, none of the 13 managers killed it. A separate group of 20 academic experts in capital budgeting, given only an analysis of keeping the product versus killing it and no stake in the launch, killed it every time.

The sunk cost fallacy, the habit of throwing good money after bad because of what's already been spent, explains only part of that result. In one version of the case, managers who had launched the product were also handed an analyst's report showing the company would come out ahead by killing it, and only 6 of 28 killed it.

In another version, managers got the same report and the same project history, but were told a colleague had made the launch decision and that they'd been brought in to evaluate it independently. They had no promotion riding on the product. In that group, 17 of 31 killed it. The biggest difference between the two groups was whether the manager deciding had made the launch call and had a career riding on it. Taking those two things away moved the share who killed the product from about one in five to more than half.

Eleven managers wrote their own stopping rule before launch. None of them killed the product, and five broke the rule they'd written.

X builds the kill into a project before it starts. In X's own description of how it works, Teller says a Rapid Evaluation team gives each new idea "a few weeks and a few thousand dollars" to expose its biggest risks, a stage that "kills many dozens of ideas quickly." Projects that survive get kill signals, "metrics that a team agrees on when the project starts" that tell the team, in Teller's words, "We should walk away from this project now." Foghorn, an X project to make fuel from seawater, was shelved after its team "couldn't deny that they'd hit their kill signals." Nine years later, Teller still talks about killing ideas the same way. At TechCrunch Disrupt in October 2025, he described what X does when a cheap test shows an idea is wilder than expected…

X put three things in place before any project started: someone whose job is to kill ideas early, a stopping rule agreed on at the start, and a reward for the team that ends its own project. The companies Kelley and her coauthors studied had the first piece, in the form of their screening, and lacked the other two. The Duke experiment shows what a stopping rule is worth without the rest. Of 17 managers who committed in advance to an analyst's stopping rule, only 9 killed the product when the rule said to. The authors favored a rule like that over bringing in a new decision maker, mainly because a second manager has to learn the whole project. I'd argue a company needs both, because a rule nobody enforces gets broken by the people it was written for.

Management researcher Isabelle Royer, who wrote about the problem in Harvard Business Review in 2003, called the person who enforces that rule an exit champion. "Exit champions take the initiative to defend exit," she told Computerworld, "which will usually lead to conflict with believers." I call those people assassins.

An assassin didn't launch the projects they end, holds the kill signals the team agreed to before the money moved, and has the authority to act on them. The assassin also needs X's third piece in place, because teams that fear for their jobs let projects drag on, which is exactly what Kelley and her coauthors found. At X, ending a project earns a bonus and a promotion.

Keeping a failing project alive breaks no rule, and in the companies Kelley and her coauthors studied it was the default. In May 2025 I suggested keeping a kill list so the ideas you stop count as progress. That advice put the burden on the individual, and the Duke experiment says the person who launched a project is the one least able to end it.

Ask who at your company was rewarded last year for ending a project. If nobody can name anyone, ask who has the authority to end a project they didn't start.

If the answer to both questions is nobody, the projects your company started this year will still be tying up its people next year, whether they're working or not.