Incident Story Time

Every Wednesday morning at work, a handful of folks join me to share stories of incidents. It’s a session that never ceases to surprise me, regardless of how many people attend.

The meeting is kept to an hour and the list of incidents is limited to the preceding week. The discussion can start by picking them from a list or asking for any volunteer topics. We even earmark incidents during the week as something good to talk about in “story time”.

Incident Story Time!

#

I started doing this four jobs ago, about six years back. Weekly operational reviews were already commonplace. Like I have seen many times over, these reviews focussed on counting stuff. I’m not here to disparage people who feel the need to count stuff. But the format is light on opportunities to learn.

I suggested we should make this a weekly meeting that told the stories of incidents. As a title, “Incident Story Time” fell naturally into place. In that job and in every job since, I’ve established this weekly discipline.

At each one of these companies the situation was somewhat the same: opportunities to learn how people do their jobs and how we can learn to work together better were being left on the table. Sometimes the meeting wasn’t happening at all. Sometimes no incidents were being reviewed at all. Or the reviews just counted stuff and asked the same boring, forgettable surface questions about whether we were good or bad.

It goes like this.

#

• Invite people who respond to incidents and make the meeting optional.
• One person should facilitate. I run it a little like we’re doing a podcast where I’m the host and try to give everyone a chance to speak.
• To start, pick an incident from your list. We tend to go with those that would not otherwise be discussed, but there’s no hard rule here. Minor incident without a PIR? Put it on the list.
• Don’t expect to get through the whole list. If you get through two, that’s huge.
• Pull up the incident timeline if you have it, an incident Slack channel is enough. Let this be the anchor for asking how things went down.
• I try to keep the discussion on-track and guide with qualitative questions about what happened, asking how things occurred at each step of the way, allowing the discussion to flourish naturally.
• I like to remind people that this is the place to get in the weeds. We often don’t get such opportunities during official PIR Debriefs, so I want to give people that chance.
• If there are no incidents to discuss, ask questions about how on-call went this week, or if anyone has been having any issues with the process or tooling. Does anyone know of any near-misses?

Story Time Tips:

#

• Be curious. I can’t say this enough. Listen to people and let their words be inspiration for your questions. I find that if I’m really listening to someone, it’s effortless for me to be curious about some intricacy of what they’re saying or doing. If a word surprises me, I say something about it.
• To find deeper spots where learning can be found, ask people what they usually expect during these kinds of situations. What made this time different? Was the playbook accurate? What other events or processes were happening at the same time? Were there any distractions?
• A good conversation starter is to ask what kind of production pressure was felt while responding. It can be asked to everyone in the meeting, even asked about the customer. I’ve been amazed at the differences.
• There is great advantage to asking obvious questions. Experts cannot resist setting assumptions right or explaining how their specialty works. So even if I know exactly what something is, I will ask for a definition or an explanation as if nobody in the room has any idea what it is.
• Someone will assuredly start this discussion by giving a summary because that’s what people are used to other people wanting to know about incidents. Let that happen, but drive the discussion to individual events and actions of the people involved. No item you see on the timeline is too small.
• Ranting will happen. It’s valuable because it tells a story itself, where responders are having difficulties. Explore these topics but steer away from blameful language. We want this to be a safe place so people feel free to speak openly.
• Tech people love telling war stories, allow it! Making those mental connections is important, but like the summarizers, the war-story-vets can tend to go on and on. The timeline is your friend here, but if you need to set bookends for everyone, announce that we’ll talk about this incident for the next 10-15 minutes and then move on.

But Why Stories?

#

Incident Story Time has proven to be popular in every place I’ve founded the practice. I think it’s because people like to tell stories. We like to share in the experience of how someone else managed a problem or made a decision.

It’s connective labor at work, it’s generative and inclusive. We create community this way, we feel a sense of belonging, we relate to each other, build empathy, learn how to go about a process, or discover something new.

Putting stories in the context of an event like problem-solving during an incident can be magical to watch. The more we can make our official debriefs be like these informal stories, the better, because I always see the lightbulb go on for people during IST.

It has become one of the things I look forward to every week at work, I love seeing a community of practice come together. Putting the discipline into a regular weekly meeting like this goes a long way towards a grassroots culture of resilience.