Twitter, now that we understand why the preventable problem paradox is so prevalent and pernicious, it’s time to talk about combating it.

So, as promised, here’s a thread on pre-mortems.

In this thread, we’ll look at the “what” and “how” of pre-mortems, along with a novel technique of using “Tigers”, “Paper Tigers”, and “Elephants” to run effective pre-mortems.

But first, ICYMI, check out the thread linked below.

While I knew that thread would resonate with some, it got way more popular than I had imagined.

It seemed to especially strike a chord with folks in security, sysadmin, privacy, and related areas. https://twitter.com/shreyas/status/1218724150312751104

And many of you shared (both publicly and in private) how it clarified some of the organizational dysfunctions you’ve seen over your careers.

This Tweet is quite relevant: https://twitter.com/shreyas/status/1221149166807568384

With that, let’s talk about a specific technique to help you do what’s right for your customers, your company, your team, by foreshadowing and mitigating the most blatant would-be blunders.

That technique is pre-mortems.

It is one of 3-4 mitigations for the preventable problem paradox.

It is also the most practicable one.

You can literally implement this on Monday if you want.

Post-mortems, after action reviews (AARs), etc. are becoming a part of the “standard process” at many organizations.

(and I think that is great!)

So, what’s a pre-mortem?

Note: you can (and likely should) do a post-mortem anyway, even if the project went quite well.

But, moving along.

Unlike a post-mortem—where you discuss what went wrong (and what you can learn from it)—in a pre-mortem, you get together earlier in a project’s lifecycle and ask the team to assume that the project has failed.

And you prompt the team to come up with the reasons why.

This short and excellent HBR article by @KleInsight is required reading on this topic. https://hbr.org/2007/09/performing-a-project-premortem

Here are the highlights of the standard pre-mortem process:

I’ll now share a modified pre-mortem script that has worked well on the teams I’ve worked with.

As background, at Stripe, the teams I’ve led have regularly run pre-mortems for our products, particularly major product launches (e.g. Stripe Connect, Stripe Terminal).

And while we haven’t been 100% mistake-free, pre-mortems have enabled “calm product launches” and enhanced team productivity & morale.

Why change the standard pre-mortem script?

In my experience, the standard pre-mortem meeting was very engaging *while* the team was in the room.

But how many times have you had an engaging meeting and then people leave the room and everybody forgets about it and reverts to old patterns?

That’s what I saw repeatedly when we employed the standard script.

So, I began looking for ways to change that.

I wanted the team to

A. be spotting major problems, and
B. surface those problems up to other team members

*throughout the lifecycle of the project*,

not just at that one pre-mortem meeting.

What was missing, I realized, was an evocative, convenient lexicon that allowed people to talk about these things in a psychologically safe manner.

Related: I learned quite late in my career the tremendous benefits of giving your team a context-specific lexicon. Don’t be me.

Enter the metaphors:
Tigers
Paper Tigers
Elephants

The way I like to run pre-mortems now is to ask them to list out their concerns about the project in 3 different categories:

Tiger

Paper Tiger

Why are you not worried about a Paper Tiger (even though others might be)?
Usually because you’re responsible for the said area and have strong conviction that the ostensible Tiger is fully under control.

You’ve got it!

Elephant

An Elephant might not be a threat per se, but it’s the thing you’re worried no one is talking about.

It’s the “elephant in the room”.

So, with this lexicon, here’s how I recommend running a pre-mortem meeting:

It’s 1 hour long and the flow looks like this:

During the context setting part, I introduce the pre-mortem concept (it’s always *someone’s* first pre-mortem) and ask everyone on the team to come up with:

2 Tigers (at least), and
any Paper Tigers and Elephants they can think of.

There is absolutely no talking during this time.

Quiet time!

It’s amazing how long & productive a 10 minute stretch of silence can be in a meeting, when no one is talking.

After that, there’s another 10 minutes of Quiet time.

During this time, people read everyone else’s Tigers, Paper Tigers, and Elephants.

And they get to +1 others’ Tigers, Paper Tigers, and Elephants. Each person can give up to five +1s. So you need to be quite selective.

Btw, this is all being done in a shared Google doc or a Dropbox Paper doc. One advantage of Paper being that you can easily see who wrote what.

And then, Quiet time is over.

You go around the room, and people share their observations (e.g. what Tiger resonated the most, what they found surprising, etc.)

And, as the facilitator, you wrap the meeting up by summarizing the top themes that have emerged from the pre-mortem and sharing what people can expect next.

So, what’s next?

It’s the most important part of the entire process.

The pre-mortem action plan.

As the facilitator, you prioritize the top N Tigers / Elephants that emerged from the pre-mortem exercise.

You create a document that summarizes the action plan and share it with the team for commentary.

Here’s a hypothetical example:

Note that your goal isn’t to list *every possible problem* in the action plan.

You must focus on the major problems (i.e. the deadliest Tigers), and be fine with living with the minor ones.

You cannot (and should not) fix all problems because you don’t want progress to grind to a halt.

But more importantly, I’ll observe that solving one problem often creates a different problem.

So you’ve got to have clarity on which problems you’re willing to live with and which ones you can’t live with.

(this is perhaps applicable outside of one's work life too)

Also note that it’s important to list the verbatim Tigers and Elephants (as in column 2), since it reassures team members that their *direct input* was useful.

Every item must have a single Directly Responsible Individual (DRI). (they can of course delegate, as appropriate)

And the last column lists the proposed mitigating actions,
in priority order,
that will *reduce the chances* of the problem occurring, OR
will *limit its negative impact* if it does occur.

Once you’ve reviewed the action plan with the team, make sure that you track progress against the action plan during the rest of the life of the project.

You can do it by merging the action plan with the overall project plan, so it becomes an integral part of “how we do things around here” vs. a one-off effort.

So that’s pretty much it.

How do these pre-mortems help the team?

Besides the obvious benefit of reducing the chances of major mistakes, I love it when team members wholly adopt the “Tiger", "Paper Tiger", "Elephant” metaphors.

It’s quite typical that, N days after the pre-mortem meeting, team members will say in a meeting/on Slack/email:
“I recently thought of a Tiger that’s been worrying me since”
“Remember, that’s the Elephant that Bob pointed out earlier. We still need to do work there.”,
etc.

Saying in a meeting “I’d like to talk about a Tiger” is lower pressure on the individual than dealing with the fear (rational or not) of coming across as “pessimistic” or a “naysayer” when expressing their concerns in normal English.

These metaphors can be quite powerful!

And by calling out the importance of spotting deadly Tigers and talking about the big Elephants, you create more psychological safety for team members to bring up their concerns.

After a well-run pre-mortem meeting, observe your team members as they exit the meeting. Odds are high that their faces will look more relieved, their gait more optimistic.

Why?

Because the problem that had been worrying thus far them is no longer just THEIR problem to carry.

This catharsis can by itself be priceless.

Last week, I ran a (highly unscientific) Twitter poll to assess how common the practice of pre-mortems is.

Only ~10% regularly run pre-mortems. https://twitter.com/shreyas/status/1220389045752123398

So, my request is simple:

I'm hopeful

I hope more pre-mortems will mean:
fewer privacy gaffes
fewer security issues
reduced system downtime
fewer “should-have-succeeded-but-actually-failed” products
clearer policy change communications
better-run events
less user misunderstanding
and ultimately, happier customers.

This Tweetstorm is getting quite long (even by my standards), so I’ll stop here for now.

I have some more draft Tweets on this topic (including answers to a few FAQs).

As an experiment, I’ll ask you to post any questions you have by replying to this Tweet.

And I’ll commit to responding to the most relevant questions.

Many thanks to @tarstarr @amy @jay_ssh @JorgeO @blattus @DeveshSenapati @benzguo and the rest of the Connect & Terminal teams at Stripe for running (and at times, letting me run) pre-mortems over the years.

These ideas wouldn’t have developed without your support.

EOF

Here’s a template you can use for pre-mortems of the style described in this thread: https://twitter.com/shreyas/status/1380322025688817664