On 7/29/22 8:48 AM, Bob Bridges wrote:
Some of my favorite military authors talk about the dreaded post-battle analysis, in which a board sits on the officers involved and asks lots of penetrating questions: Why did you make that choice? If the enemy had done this, what would have been your options? Did you receive intelligence notification SR-45T, dated such-and-such, about the enemy's new tech, and did you take that into account when you arranged your forces?
I remember the some time in the last 5-10 years hearing the "Blameless RCA" phrase and liking it. Then people went and spoiled it.
My intention behind blameless RCAs is to understand what people did, why they did it. Sort of like trying to glean insight into their brain's L1 cache at the time during the incident. -- There was /some/ amount of sanity checking of the data / algorithms people applied. -- But I always wanted to understand their state and how altering the state next time might change things.
In some ways, it's like the Flight Data Recorder. The FDR in and of itself doesn't place blame. It may well show that the pilot did something in error. It may also exonerate the pilot if there was a mechanical malfunction or external influence.
Sometimes the outcome of such an investigation will be training. Sometimes the outcome of such an investigation will be a process change. Sometimes the outcome of such an investigation will be new safety guards so that someone doesn't stick their hand in front of a moving knife.
I understand why it feels to the victims as if the purpose is to spread blame around.
In my (not so) humble opinion, if the person being asked the questions feels like they are being blamed, then the person asking the questions is doing it wrong.
But this is the time to look at everything that happened and see what should have been done differently. It's a great time to answer honestly "in the press of the moment, I never thought of that option", and "our logs show that we received that communication, but I don't recall it".
#truth
Blame, shmame; the board presumably knows what happens in "the press of the moment", and this is my best opportunity to improve my decision-making.
Sometimes it's best to mute a low priority alarm so that people can focus on higher priority alarms. ;-)
(Which sounds heroically rational, but I still get all defensive during coding reviews.)
I think there is some room for improvement in how people ask questions during code reviews. E.g. "Please help me understand what you are doing here and why you are doing it that way?" As if a student asking a teacher a question.
Conversely, the ""teacher needs to be both receptive and open minded to such questions from the ""student.
-- Grant. . . . unix || die ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
