Shreyas Doshi: evaluation

Transcript context

…Yeah, we're all familiar with a post-mortem or as they call it in the military, I think, after action reviews, right? So every company I've worked at, we've had some form of post-mortem when a launch had problems or an initiative did not go as planned or we suffered an unacceptable system downtime. somebody would say, oh, we need to postmortem that. And over the years, I really saw the effectiveness of a postmortem, right? Some really great insights came out of a postmortem about what went wrong and what we could have done better. And as I saw the effectiveness of a postmortem, that's what made me wonder, why do we need to wait until after things go wrong? Because like, why can't we extract these some of these insights before they go wrong? So it was around that time that I discovered the idea of a premortem. I learned about it from a Harvard Business Review article written by Gary Klein. And the idea is simple, which is when you are working on an important project or initiative, you get together with your team often. early on in the products or the project's life to see in advance what could go wrong and the way i describe a premortem is that if you do a premortem right you will not have to do an ugly post-mortem you might still do a post-mortem to learn but odds are very high that it is not going to be a bad post-mortem And the genius of the premortem ritual is the initial prompt. So it's not just about like, well, what could go wrong, right? Like the initial prompt is the genius, which is the prompt starts with, imagine this project that we are working on has failed six months from now. or this launch we are doing has miserably failed. Let's just all imagine that. Now, let's work backwards from there and ask ourselves, what went wrong? What could have contributed to this utter failure? And that's how... A premortem meeting will start. The leader will start with this prompt. And then the way the meeting goes is you ask your team members to share what could have caused this utter failure. And the magic of this type of approach where you kind of like work backwards from a failed outcome, a hypothetical failed outcome. is that it just somehow enables two things. One is much greater psychological safety for team members to talk about things they're concerned about, but that they were just hesitant to bring up because nobody likes to be negative in modern organizations, right? Everybody wants to be optimistic and positive. So a premortem setting gives everybody the license to actually think about what can go wrong. So that psychological safety is a big, big factor in why a premortem works. And what I've found is in, you know, at Stripe, I did this regularly with launches that my team was involved in. Sometimes, you know, some teams or some people were like just surprised or skeptical, like, is it really going to work? And then we go through the pre-mortem meeting and there's a whole process that we can talk about. ow, some teams or some people were like just surprised or skeptical, like, is it really going to work? And then we go through the pre-mortem meeting and there's a whole process that we can talk about. But like, as we complete the meeting, I I ask everybody, so how did that go? And just everybody's smiling, even though we've spent, say, 30 minutes or an hour just talking about terrible scenarios of things that could go wrong. But everybody's feeling a little lighter, right? Because it's great catharsis for them. So that becomes really important. And the last kind of thing I found with premortems, now that I've done them with various other companies as well that I advise and whatnot, is the shared vocabulary. And the shared vocabulary that you get about being able to talk about things that will fail. So I have a specific approach, which is I ask the team to talk about three things. Each member on the team should bring up three things. One is a tiger. So you can bring up tigers in the shared doc that we create. And a tiger is a threat that will actually kill us, just like a tiger would. So these are like attributes. actual problematic things that could be really harmful to the product or the project. So that's a tiger. The other is paper tiger. So this is a seeming threat that others might be worried about, but you're not worried about. So that's the paper tiger. And then the last one, and I think this one was also used at Airbnb in other ways, is elephant. And the elephant is the elephant in the room that nobody's talking about. So it might not be a tiger. It won't kill us. But you're still worried that we are not kind of like seeing reality as it is that. And so an elephant could be like, well, we are assuming that just because we launch this and do a bunch of PR that we'll get users. But are we sure we're going to get users? Right. Like that's kind of like the elephant in the room that nobody's talking about that. Like, again, this gives you that psychological safety to bring it up. And then what I noticed as I ran premortems is that in future meetings that the team had, where I wasn't even present, people started talking about, oh, I have this tiger. Can I bring up this tiger? And all of a sudden it became okay for people to bring those things up, which I think is perhaps the best part about a premortem is that shared vocabulary. Such a simple idea that is clearly going to benefit you and your team. And it's interesting that people don't often do this or haven't even thought about doing this. And so just to get a little bit deeper, how do you actually execute this meeting? Who do you invite? What are the questions you ask? When exactly do you do this, that kind of stuff?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.