PostMortems and Proactive Learning From Events
Thanks in advance! I'm John Allspaw, author of this article:
and I'm looking to understand what engineers in software-reliant companies need in learning better from post-incident reviews.
Do you consider "post-incident" review meetings to be a valuable setting to learn NEW things about how your technology works?
On the topic of "postmortems" and proactive learning - for each of the items below, which ones ring familiar to you as something you think your organization needs to improve on?
Anticipating the next incident in order to prevent it.
Getting better at responding (diagnosis, generating hypotheses, coordinating corrective actions between people and teams) to incidents when they arise.
Learning from past incidents in deeper ways - extracting more and better learnings from incidents
Getting better at detecting when incidents might begin, or when small/minor issues might escalate into bigger issues.
Training engineers to be better responders to incidents
Convincing management or non-technical leadership to invest in any of the above capabilities.
Do you follow ITIL/ITSM "incident/problem management" guidelines?
I don't know
These are statements we've heard from across the industry - which ones resonate with you?
"We do postmortems but don’t make any progress with remediation items!"
"We have PMs, but they’re just checkbox rituals - we don’t really learn, just fill out the template(s) for management."
"We have the potential to learn so much more than we do in PMs but we don’t have great facilitators - they need some training to be good PM facilitators."
"There’s a weird power dynamic around postmortems and we aren’t learning when senior people (management or not) are participating."
Page 1 of 1
Never submit passwords through Google Forms.
This content is neither created nor endorsed by Google.
Terms of Service