Shreyas Doshi: recommendation

Transcript context

…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? Yeah. And so as I started doing premortems, they got more and more popular at Stripe. Other teams started doing them. And then afterwards, I, you know, helped some startups kind of also do premortems. And at some point, I decided I should just like write down my template for premortems. So I worked with the folks at Coda to create a Coda doc, which you can find and we can put in the show notes if possible. Basically, that's an entire kind of template for how to run premortems. Using this method that I talked about, including tigers, paper tigers, elephants, all of that. The main thing about a premortem is to include people from every function that is going to be involved in, say, if you're doing a launch. And so if it's a really large launch, sometimes I will separate it into two groups. One is everything related to kind of like the engineering side of things. where you can kind of bring in, usually the engineering team is fairly large, so you can bring in every engineer. So that's really important. Every engineer needs to be in the meeting. And so it might be a meeting of 10, 15, 20, whatever engineers and maybe a PM, maybe a design counterpart and so on. That's just focused on the product engineering side of things, like what could go wrong. And then again, for a large launch, I like doing a separate premortem for the go-to-market side. And so that will involve sales team, support team, marketing team, involved design team. Some of the core engineering leads will also need to be at that meeting. Over there, we'll talk about more of the go-to-market risks. So that's what I like to do for a very large launch. For a smaller launch, I just like to do one meeting where everybody's present. And like I said, start with the prompt of imagine this has failed. So as the premortem meeting leader, it's my responsibility to share the prompt. And then I like doing these premortems where we alternate between speaking and quiet time. So I'll share the prompt and then I'll say, okay, now the next five minutes or the next 10 minutes is quiet time where I already have that template, like the CoderDoc, where people start entering their own kind of tigers and paper tigers and elephants in a way that nobody else sees. And so people do that. And then we go around the room. And kind of share. And the one other innovation I added as I did this often was I also, after people shared, I asked people to pick the tiger that they find more scary, but that somebody else mentioned. So not their own tiger, but some other tiger that somebody else mentioned that they found more scary. So that ends up being a sort of, you know, people basically are voting. And then as the premortem leader, it's my responsibility to take all of that like output that the team has generated in this document and then prioritize. Because again, the point is not to solve every problem, right? The point is to identify threats that we are not talking about openly or that we might just be missing. his document and then prioritize. Because again, the point is not to solve every problem, right? The point is to identify threats that we are not talking about openly or that we might just be missing. Or we might be assuming that somebody else is going to deal with it only to find nobody was thinking about it. So then I like to create a post-premortem action plan. and then share that with the team and kind of keep myself as the leader accountable for actually making progress on it. Having started doing this,…

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