How Could This Have Been Prevented? The Art of the Pre-Mortem

Originally posted on the Truss blog

In the world of disaster response, teams engage in something called a “hot wash” after each deployment. If something went wrong, we ask ourselves: How could this have been prevented? It’s a question that helps us mitigate crises rather than simply respond to them. Sometimes, if a responder is about to do something particularly ill-advised, say in a social context, another responder will ask them, “How could this accident have been prevented?” as they walk towards potential harm or embarrassment.

As someone who has done crisis response for the past eight years, the pre-mortem we held on my third day at Truss made me feel right at home. It was the last day of an intensive kickoff event for our DOD project (more about how we won that here). Our engineering architect Nick Twyman led the assembled team in a session to brainstorm issues which might be severe enough to tank the project. He opened with the prompt, “Imagine you’re presenting to the entire company 12 months from now and must explain why this project completely failed.”

Engaging in this practice:

  • Surfaces potential issues before they become problematic.
  • Prevents team members from suffering in silence or needlessly worrying.
  • Replaces reaction with strategy.

We’ve already benefited immensely from this practice. For instance, we learned to identify and engage early with stakeholders who otherwise might have been invisible until too late. This has allowed us to pay attention to serious concerns while also staying focused on the emerging roadmap for the project.

Where did this idea come from?

Our CTO, Mark Ferlatte, learned about the practice from Daniel Kahneman’s book Thinking Fast and Slow. He noted that it “felt incredibly weird the first time you do it.” The book covers different modes of thinking and responding to what feels immediate versus the strategic, tricks to help you move from reacting to planning, as well as how to be self-aware when in difficult conversations.

We’ve developed our own flow for pre-mortems, and have benefited in various ways.  In one instance, the team indicated that they were feeling unsure about being able to track things properly. This feedback resulted in an ad hoc training session on our task tracking tool with positive results.

How do I do it?

You, too, can avoid delays, derailments, and failures by following this process. Whether you refer to it as “forecasting” or “generalized anxiety,” there are a few simple steps.

First, think about when it makes sense to have a pre-mortem. We do ours at the end of a project kickoff (when folks have the project fresh in their minds but haven’t yet started building habits and opinions about how things “should” be). You can also run more than one for any given project. It’s particularly helpful to do during sprint planning sessions or prior to irrevocable commitments (before we sign the contract, before we begin execution on the contract, before we go live with the product).

Don’t lead the session by asking a broad question like: How might this go wrong?  Instead, be very specific. We used the prompt mentioned above, emphasizing two important factors. “Imagine you’re presenting to the entire company 12 months from now and must explain why this project completely failed.” These two aspects helped people move beyond generalized anxiety and into thinking strategically about what they are unlikely to be able to adapt to themselves. In a larger group, give everyone sticky notes and about five minutes to write down their thoughts, then group their ideas into categories while reading them out loud. In a smaller group, take a minute or so to think about it, and then go around in a circle to hear what folks came up with.

Some of the concerns raised might not surprise you. Ideally, you’re already mitigating risk around the topics some people bring up. Sometimes, though, someone will say something new or extremely obvious and scary (for example: “None of us have ever published a book” when the project is to write a book). Mark treats these concerns very seriously and attempts to mitigate them as quickly as possible (for example: hire an agent to help us navigate book publishing).

We found that those obvious and scary observations were more likely to come from junior rather than senior employees. Senior people often overlooked obvious risks because they had “always managed before.” Junior team members were justifiably concerned when they felt like the project was missing key factors, but they wouldn’t speak up if their concerns were dismissed. Yet another reason to be sure your environment is open and safe for employees to voice their concerns.

Good luck out there!

Pre-mortems are a tool to start thinking about the future and to do so strategically rather than reactively. This helps teams avoid pitfalls and focus their work. Pre-mortems are easy to hold and can happen at multiple points during a project’s lifespan.

May all of your difficulties be novel, and good luck out there!

Open Source Cadavers

Written by @Willow Brugh, with feedback and general awesomeness from John Willbanks, Sam Klein, and Michael Stone. Additional props to Adrienne and Sands for edits, and to Fin and Matt for kicking my butt into delivery.

In loving memory of my crypto-loving, open-access enthusiast, and occasionally suicidal friends. We will build more open worlds with our corpses. I just wish you would have held off for more unavoidable causes.

Early this year, yet another friend of mine up and died. There was of course a mess of things that had to be figured out. It wasn’t just the traditional things of cleaning out her house (I wasn’t around for that part) or figuring out the funeral (Viking in variety). It was new and interesting technical and moral turmoil of getting into her hard drive, questions of “should we even?”- her prolific music and authoring contributions rivaled by her extreme privacy. It was seeking the edges of her far-flung pockets of internet community to notify them personally, racing the deluge of social media notifications, not wanting them to find out about her the same way I found out about my grandmother – before the familial phone tree had reached me, a peripheral friend calling me based on a facebook post from my sister. A morbid seismic wave.

While I don’t have any control over how others plan for (or don’t) their demise, I have a say over my own. I can show my care for people dear to me my own compulsive, facilitating way by being sure they find each other as they find out, and in making sure information and knowledge I have to offer continues to be released under open access, even if I’m not there to do it. From doing humanitarian and disaster response (and just a general “awareness of the abyss,” as my mother used to tell my vast and angry younger self), I have had to face the looming possibility of my own death head-on. The networked reality that brought those strange new questions and moral quandaries for my friends’ deaths can instead be used to carry forward care and knowledge. This is a sort of guide for the bits of postmortem planning the internet and most lawyers have missed. It’s not complete – I’ve run into some interesting blocks and quirks, around which I’m eager to collaborate with others.

This post is less about things like wills (what happens to material possessions, who doles it out, and the like) and living wills (if you want to be kept on life support etc) – although I’ve added the templates I used to the wiki associated with this post as it includes digital artifacts and more awareness of gendered pronouns than other bits of the internet. This write-up focuses on specific aspects for Open Access and encryption enthusiasts. Brace yourselves for a morbid entry. Know I’m peachy keen, and being an adult about things, not in danger of harming myself or others. If you are in danger of harming yourself, please say as such directly, and get help, rather than indirectly through things like estate planning. It should be possible to speak about death without fear – that’s what I’m doing here. I hope you can hear it (and act) from a similar place.

I’ve divided components up into documents, accounts, notifications, and people. Documents are centralized with accounts, which are propagated via notifications to people, as triggered by a notification from a person. This means I only have to worry about keeping something up to date in one place — a change to a will or to a website password simply happens in the place of storage, without needing to notify everyone involved. As people become close to me, or exhibit destructive behavior, they can be added or removed from the notification pool. The notification mechanism is the one thing that has to remain consistent in this set up. Continue reading