A few weeks ago I gave a talk at the DevOps Enterprise Summit London (which was virtual).
The description of the talk:
In the past two years, we have had the opportunity to observe and explore the real nitty-gritty of how organizations handle, perceive, value, and treat the incidents that they experience. While the size, type, and character of these companies vary wildly, we have observed some common patterns across them.
This talk will outline these patterns we’ve discovered and explored, some of which run counter to traditional beliefs in the industry, some of which pose dilemmas for businesses, and others that point to undiscovered competitive advantages that are being “left on the table.”
These patterns include:
-
- A mismatch between leadership’s views on incidents and the lived experience that engineers have with them.
- Learning from incidents is given low organizational priority, and the quality and depth of the results reflect this.
- “Fixing” rather than “learning” – the main focus of post-incident activity is unfortunately treated narrowly as repair, not learning.
- Engineers learn from incidents in unconventional ways that are largely hidden from management (and therefore unsupported).
Here is the video:
