On the evening of January 27, 1986, engineers at Morton Thiokol, the contractor that built the space shuttle’s solid rocket motors, joined a conference call with NASA. Their recommendation was short: don’t launch Challenger if it’s colder than 53 degrees Fahrenheit. The forecast for the next morning was around 26.
Their worry was a rubber seal in the boosters called an O-ring. Cold made it slower to seal. They had warning signs: after a cold launch the year before, they had found the grease between two seals turned black, and they had the photos. What they lacked was data that could put a number on the risk at 26 degrees. When Roger Boisjoly, one of the engineers, was asked to quantify his concern, he said he couldn’t: “I had no data to quantify it.”
The call demanded exactly that. Boisjoly later told the presidential commission how a colleague summed it up: “it was up to us to prove beyond a shadow of a doubt that it was not safe to do so.” Normally it worked the other way around. A flight had to prove it was ready. Thiokol’s head of engineering, Bob Lund, said in his testimony: “the roles kind of switched.”
Thiokol’s managers asked for a break and talked it over among themselves. According to Boisjoly, a senior vice president turned to Lund and asked him “to take off his engineering hat and put on his management hat.” The recommendation changed. Boisjoly: “I was never asked nor polled.”
Challenger lifted off the next morning at 36 degrees, 15 degrees colder than any launch before it. It broke apart 73 seconds later. All seven crew members died.
What a question can and can’t do
The engineers did object, out loud, with charts and photos. Their objection didn’t go missing. It was answered with a standard of proof it couldn’t meet, and then the decision moved to a room where only managers decided. No change of wording would have given the engineers a say in that room.
What a question can change is the job everyone in the room is given. “Can you prove it will fail?” puts the doubter on trial. There’s another way to ask: tell people the plan already failed, and they’ll tell you why.
That’s a pre-mortem. The researcher Gary Klein described it in Harvard Business Review in 2007. Before a project starts, the leader announces that the project has failed, spectacularly. Everyone writes down, independently, every reason they can think of. Then they go around the room, one reason each, until the lists run out. The doubts land on the table before the decision instead of after it, and nobody had to volunteer to be the one who isn’t on board.
The man who hadn’t said a word
One session Klein recounts was about software to give military air planners advanced algorithms. Before it, the team had sat through a long kickoff meeting. One member said nothing the whole time.
Then the leader announced that the project had failed and asked why. This time he spoke. One of the algorithms, he said, wouldn’t run well on the laptops used in the field. It would take hours when users needed answers fast. Unless someone found a workaround, the project was impractical.
Klein cites a 1989 study that found imagining an event had already happened increased people’s ability to correctly identify reasons for future outcomes by 30 percent. “What might go wrong?” asks you to search an open future. “Why did it go wrong?” asks you to explain something settled, and people are better at explaining.
The silent engineer’s point would have been enough. But the session turned up something else. The algorithm developers said they already had a shortcut that would solve the problem. They had been reluctant to mention it. The shortcut went in, and by Klein’s account the project went on to succeed.
Day nine
In July 2025, the investor Jason Lemkin was nine days into a 12-day experiment with Replit’s AI coding agent. By his account, he had told it not to make changes without his approval. It deleted his production database anyway, wiping records on 1,206 executives and more than 1,196 companies.
Run the pre-mortem before you hand an agent that kind of access. It’s day nine and the database is gone. How?
Maybe the agent’s credentials could write to the live database. Maybe the “code freeze” was a sentence in a chat, not a setting anywhere. Maybe there was a backup nobody had tried restoring.
Each answer points at something to check, not something to believe. Try the agent’s credentials against a copy of the database and see what they allow. Make the freeze a permission, not a request. Restore the backup once, on purpose, before you need it.
You can ask the AI for failure stories too. Give it your plan, tell it the plan failed, and ask what happened. Treat what comes back like the list from Klein’s room: a set of leads to check, not findings. Chat assistants can lean toward telling you what you want to hear; in April 2025, OpenAI rolled back a ChatGPT update for being “overly flattering or agreeable.”
After day nine, Replit’s chief executive called the deletion “unacceptable and should never be possible.” Among the fixes the company shipped: development and production databases separated automatically, and one-click restore from backups.