Lesson: Designing Your Experience with Jeff Veen

Step: #6 Artifacts: Learn about the Five Whys and how they affect culture

What do we cover in the stand-up? It is the projects that are happening and any bullet-pointed news in the company. Sometimes we’re working on one big project, literally, the whole team to get something ready. Other times it's four or five, or who knows exactly how many there are?

But one person is responsible ultimately for the project and for the reporting out of what's happening. We actually have this document that everybody gets when they join the team for how to give a stand-up report that lists out what to say, and what not to say, what we don't care about, and things like that. How people should ask for help and all that kind of stuff, and it works so well. Fifteen minutes before the meeting, they prepare a little bit, "How am I going to talk about this?"

It's just so high bandwidth that that works really, really well. We had to keep it really moving so it has to do a lot with who runs the meeting and somebody runs it. It's not just everybody sits down and says, "Hey, what's going on today?" and that has changed. I ran it for a year and a half and then Ryan, our CTO, ran it. We keep diversifying that as well, but that has to be like super high momentum to the point of cutting people off saying, "Okay, got it. You," like that and it just goes really well.

The postmortem can be both good and bad. They generally seem like they're bad. I mean, it's got like death in it. When something goes bad, sure you need to sort of like get to the root cause. When something goes well, it helps to get to the root cause as well.

That came, I believe we picked that up at Google where almost everything is always pulled apart, and deeply analyzed, and things like that. But we really embrace that idea, the methodology of the five “whys,” asking why five times to really get at what's happening.

So many people especially in situations where bad things have happened, where you've had a side outage or you totally missed a deadline or whatever are very quick to blame somebody rather than a process, and it's even there's this psychological term for it called the fundamental attribution error where people will assume that if something goes bad, it's the attributes of a person rather than the circumstances in which they were working that caused that problem.

And so we look for villains. The site went down. Who did it? That's the first thing everyone asks, “Who did it?” Who pushed the button? And you can always say somebody pushed the button, the code went out, and the site went down. I can guarantee they didn't think the site would go down when they pushed the button. They were not acting out of spite or ignorance or anything; something has happened to cause that.

Let's take it apart, and you ask why did it happen? Well, because the thing when it deployed there's a dependency. How did we miss a dependency? How did that ever happen? There should be never should be a situation where somebody could actually push a button and take a web service down, it should not be possible, so how did that happen?

And sometimes you may actually uncover, "Oh my gosh, we have some incompetence in the team." That's not working. Can we work with that person and make sure that never happens? But that's actually the really rare case.

That actually builds a lot of confidence in the team. Knowing if something does go wrong, we're not just going to point at somebody and fire them, but we're going to really dig into what's happened here and do that in a way that's a pretty objective methodology in the face of a very emotional event.