Tag: ouch

  • The dangers of “who” and “why”: post-incident reviews

    The dangers of “who” and “why”: post-incident reviews

    Originally posted 23 September 2023 on Medium.

    Five valuable lessons, including one that really threw me for a loop when I read it.

    In one of his LinkedIn posts, Jeff Gallimore posted some thoughts about retrospectives and post-incident reviews:

    Just a PSA and periodic reminder about things to keep in mind when conducting retrospectives and post-incident reviews.

    1. No one comes to work to do a bad job.
    2. Everyone is doing the best they can given the information they have at the time.
    3. There is no single root cause. There are multiple contributing factors.
    4. Counterfactual thinking (i.e., “I/We should have done…”) isn’t productive.
    5. Leading with “How”, “What”, and “Tell me more about…” is more constructive than “Why” and certainly “Who”.

    Psychological safety. Learning. Generative culture.

    Now, the first four reminders are important, and I’ve been getting better at catching myself as the years go on. But that fifth one was a new one for me, and I’ll admit, it stung a bit when I read it, because I often ask why and who.

    A dark hallway with a large glowing question mark on the wall at the end.
    My image search here was for “investigation”… this felt about right. Photo by Emily Morter on Unsplash

    Asking “who”

    I have no intention of assigning blame. I don’t find the “blame game” useful. Usually, I’m not trying to exonerate myself or my team, although I can admit to there being a little bit of motivation to do that. Mostly, when I’m asking “who” or “why” questions, I’m trying understand what happened so we can figure out what needs to be addressed. Specifically, if I’m trying to find out who was involved, it’s only because I want to know what they were experiencing in that moment. It seems like only someone who was there can truly report on what was happening at the time.

    That said, I’ve had people refuse to tell me who did something. At the time, this was frustrating. My thought was: how can I prevent this problem from happening again if I can’t even talk to the person involved to find out what was going on?

    Just reading that thought back to myself, though, raises a good counter-argument: why does it need to be me who finds out what happened and figures out how to prevent it?

    If you’re guessing that I’m thinking of a specific instance, you’re correct. In this scenario, the team affected (mine) and the team that appeared to have caused the problem had a history of conflict. Trust was low on both sides.

    I can only guess that when they saw someone asking “who did this,” they were motivated to protect one of their own from possible criticism. I might have believed that I would interview that person without blaming and shaming, seeking only to understand and to help. But I hadn’t established that trust with the other team, so they had no reason to share that belief. It makes sense that asking “who” would put them on the defensive. Not helpful.

    Could I have asked “why” instead? Would that have been better?

    Asking “why”

    Consider this scenario: A problem was caused (at least in part, see Jeff’s point #3 above) by someone doing action Z. Let’s forget about who this person is. Shall we ask instead: why did this person do Z?

    Let’s start by assuming that whoever did Z was doing the best they could with what they had (see Jeff’s points 1 and 2 above). They didn’t come to work intending to cause a problem. Maybe they:

    • truly believed Z was correct (or that they were doing it in the correct way)
    • did Z without even realizing they were doing it
    • did good thing Y that in turn set off Z unexpectedly
    • did Z believing it WAS good thing Y
    • knew Z was trouble, but they believed they had to do it
    • didn’t actually do Z at all

    The list could go on and on. Then behind those things there are often other layers: overworked operator, lookalike buttons, alarm fatigue, things changing without notice, culture of fear, information not flowing as expected.

    Each of these suggests a different strategy for preventing this from happening again. Maybe someone needs information, training, or just rest. Maybe a misunderstanding needs to be cleared up. Maybe some easily confused things need to be clarified and disambiguated. Maybe speaking up needs to be made safer. Or maybe we need to keep working to identify the cause and the fix.

    Again, though, I think it comes back to trust. I have, in the past, tried asking “why did you do this?” or “why did this happen?” as gently and kindly as I could, with people who I thought would trust me… but the responses usually don’t help. “I’m sorry” is one common response — no matter how gentle I think I am, the person still senses danger and apologizing seems safest. “I don’t know” is another common response.

    Nobody ever says “because I thought it was the right thing to do,” or “because I’m tired from long hours and I got confused” or “because the instructions weren’t clear” or…

    I don’t think asking “why” gets me anywhere.

    How and what to do instead

    Jeff’s post has helped me identify that I have some strategies that don’t work. His suggestions of “How” and “What” and “Tell me more about…” seem like good places to start.

    I’ll assume here that we’re avoiding confrontational non-questions that are really attacks in disguise (“How could you do something like that?” and “What were you thinking?” aren’t especially likely to bring on collaborative problem solving.

    Maybe the “you” in these questions is at the heart of the problem. I can see where that might put the focus on a person, rather than on a situation, a process, a circumstance. Does focusing on a person run afoul of Jeff’s fourth point — that counterfactual thinking isn’t helpful? We might be avoiding blame, but are we still ultimately talking about what “should have” or “should not have” happened? This person should have had more training, the documentation should have been clearer, the alarms should not have been so numerous, good thing Y should not have triggered Z?

    Perhaps the key is switching to a future focus. How can we prevent this from happening in the future? What could be done to improve the process? How could we make situations like this easier and safer? Tell me more about any barriers you see that could be removed or strategies you’ve thought of for doing things better. Engaging people in the problem solving, rather than trying to be the solver myself.


    I posted this on LinkedIn in 2023. But here or there, I’d love to hear your thoughts about how you’ve approached this. What have you found useful in place of “who” or “why”?

    Originally posted 23 September 2023 on Medium.