Tuesday, March 2, 2010

A guideline for postmortem communication

Building on previous posts, the following is a proposed Guideline for Postmortem Communication:

Prerequisites:
  1. Admit failure - Hiding downtime is no longer an option
  2. Sound like a human - Do not use a standard template, do not apologize for "inconveniencing" us
  3. Have a communication channel - Set up a process to handle incidents prior the event (e.g. public health dashboard, status blog, twitter account, etc.)
  4. Above all else, be authentic - You must be believed to be heard
Requirements:
  1. Start time and end time of the incident
  2. Who/what was impacted - Should I be worried about this incident?
  3. What went wrong - What broke and how you fixed it (with insight into the root cause analysis process)
  4. Lessons learned - What's being done to improve the situation for the future, in technology, process, and communication
Bonus:
  1. Details on the technologies involved
  2. Answers to the Five Why's
  3. Human elements - heroic efforts, unfortunate coincidences, effective teamwork, etc
  4. What others can learn from this experience
Posted by Lenny Rachitsky at 5:58 AM
Labels: ,

5 comments:

  1. Hello,

    I've prepared a Checklist based on this post. You may find it useful: A-guideline-for-postmortem-communication

    Regards,
    KIR
    ReplyDelete
  3. I thought I'd share my experience using this format at my company. I recently transition into a very business and end-customer facing role managing our external and portions of our internal website. In moving into this role, one of my main goals was to improve communication to my stakeholders around downtime events. Adoption of this guideline for these communications has been the single biggest improvement we've made.

    The first time I sent one out, I was completely overwhelmed by the amount of positive feedback and support I received. The key indicator of success for me was that this support was equally divided among my IT development and business stakeholder counterparts. The only area we need to improve now is the timeliness of the delivery.

    As IT folks, we struggle with this because we want to have all the answers, but sometimes this just isn't possible. We've started including "We don't know right now"-type answers and then following up later. If anything, I think this contributes to the "Sound like a human" goal and our stakeholders genuinely appreciate the transparency and honesty.

    Apologies for the long comment, but thanks so much for the great guideline!

    Jeff
    ReplyDelete
  4. I'm from the same organization as Jeff; we've found these guidelines to be very helpful and this blog to be a great resource as we design our own communication and dashboards for our new SaaS offerings. Keep up the great work!
    ReplyDelete
  5. Comments like these make this whole blogging thing worth it. I really appreciate the insight and support. Getting real world examples like this is huge for me.

    I'm actually giving a talk on this very topic in a few weeks (http://oreil.ly/9DJv5Z), that will attack the issue from a higher level. That's why it's been so quite on the blog. I'm going to post the slides/notes here right after the talk (6/23).

    If you don't mind, I'd like to quote from the comments above in the talk :)
    ReplyDelete

Subscribe to: Post Comments (Atom)