The DevOps Handbook – Enable Daily Learning

We dive into the benefits of enabling daily learning into our processes, while it's egregiously late for Joe, Michael's impersonation is awful, and Allen's speech is degrading.

This episode’s show notes can be found at https://www.codingblocks.net/episode143, for those reading this via their podcast player, where you can join the conversation.

Sponsors

• Datadog – Sign up today for a free 14 day trial and get a free Datadog t-shirt after your first dashboard.
• Teamistry – A podcast that tells the stories of teams who work together in new and unexpected ways, to achieve remarkable things.

Survey Says

How often do you change jobs?

Take the survey at: https://www.codingblocks.net/episode143.

News

• Thank you to everyone that left us a new review!
  • iTunes: John Roland, Shefodorf, DevCT, Flemon001, ryanjcaldwell, Aceium
  • Stitcher: Helia
• Allen saves your butt with his latest chair review on YouTube.

Enable and Inject Learning into Daily Work

• To work on complex systems effectively and safely we must get good at:
  • Detecting problems,
  • Solving problems, and
  • Multiplying the effects by sharing the solutions within the organization.
• The key is treating failures as an opportunity to learn rather than an opportunity to punish.

Establish a Just, Learning Culture

• By promoting a culture where errors are “just” it encourages learning ways to remove and prevent those errors.
• On the contrary, an “unjust” culture, promotes bureaucracy, evasion, and self-protection.
  • This is how most companies and management work, i.e. put processes in place to prevent and eliminate the possibility of errors.
• Rather than blaming individuals, take moments when things go wrong as an opportunity to learn and improve the systems that will inevitably have problems.
  • Not only does this improve the organization’s systems, it also strengthens relationships between team members.
• When developers do cause an error and are encouraged to share the details of the errors and how to fix them, it ultimately benefits everyone as the fear of consequences are lowered and solutions on ensuring that particular problem isn’t encountered again increase.

Blameless Post Mortem

• Create timelines and collect details from many perspectives.
• Empower engineers to provide details of how they may have contributed to the failures.
• Encourage those who did make the mistakes to share those with the organization and how to avoid those mistakes in the future.
• Don’t dwell on hindsight, i.e. the coulda, woulda, and shoulda comments.
• Propose countermeasures to ensure similar failures don’t occur in the future and schedule a date to complete those countermeasures.

Stakeholders that should be present at these meetings

• People who were a part of making the decisions that caused the problem.
• People who found the problem.
• People who responded to the problem.
• People who diagnosed the problem.
• People who were affected by the problem.
• Anyone who might want to attend the meeting.

The meeting

• Must be rigorous about recording the details during the process of finding, diagnosing, and fixing, etc.