{"id":1032,"date":"2020-05-20T09:28:21","date_gmt":"2020-05-20T09:28:21","guid":{"rendered":"https:\/\/tomgeraghty.co.uk\/?p=1032"},"modified":"2024-04-05T08:50:07","modified_gmt":"2024-04-05T08:50:07","slug":"resilience-engineering-and-psychological-safety","status":"publish","type":"post","link":"https:\/\/tomgeraghty.co.uk\/index.php\/resilience-engineering-and-psychological-safety\/","title":{"rendered":"DevOps, Psychological Safety and Resilience Engineering"},"content":{"rendered":"

The Links Between Psychological Safety, Resilience Engineering and DevOps<\/span><\/h1>\n

Note: since writing this, I’ve learned a lot more about resilience engineering and its relation to DevOps and psychological safety.\u00a0<\/a><\/p>\n

\n

Psychological safety is cited as the key factor in team performance by numerous studies including <\/span>Google\u2019s Project Aristotle<\/span><\/a> and the <\/span>DORA\/Google State Of DevOps Reports<\/span><\/a>. The <\/span>evidence shows <\/span><\/a>that teams that operate in psychologically safe environments where they can present their true selves at work, take risks, admit mistakes, and ask for support from their teammates, significantly outperform other organisations<\/a>.\u00a0<\/span><\/p>\n

\"\"<\/p>\n

However, establishing psychological safety is rarely prioritised by delivery-focussed leaders who use output-oriented metrics. Instead, these leaders tend to focus on <\/span>objectives, metrics<\/span><\/a>, and modern practices such as <\/span>value-stream alignment and cross-functional teams<\/span><\/a>. While these have great value, and will go some way, or indeed a long way, to drive performance and delivery, they are not the full picture.<\/span><\/p>\n

It can be very challenging, particularly for less experienced leaders, or capable leaders in difficult circumstances, to build and facilitate psychologically safe environments<\/a>. This is particularly true in technologically-oriented organisations where the domain is complex and failure is explicit, obvious and can generate a large blast radius.\u00a0<\/span><\/p>\n

Mistakes happen. They must happen.<\/h2>\n

In a psychologically unsafe team, a software engineer who makes a mistake in a complex system<\/a> and releases a small flaw into production that later causes an outage may be blamed for the mistake. The flaw will be easily attributable, and the impact of the outage can be significant. In many organisations, the <\/span>resultant fear of error can dramatically slow down the rate of change and speed to market<\/span><\/a>.<\/span><\/p>\n

Of course, the converse is not appealing either; it\u2019s not acceptable to tolerate errors, outages, and mistakes. Speed to market with a faulty product or service may be equally as bad as a significant delay to reach the market. <\/span>Customers do not tolerate poor quality services<\/span><\/a>, so we need to build high quality services and do it at velocity. This delivery at pace is one of the key tenets of DevOps, and an effective DevOps culture requires psychological safety.<\/span><\/p>\n

Resilience Engineering and Psychological Safety<\/h2>\n

In my work on <\/span>psychological safety in high performance teams<\/span><\/a>, I\u2019m often asked about how to achieve it, and whilst there are many general approaches that overlap significantly with principles of excellence in servant (or empathetic) leadership, there are also specific actions and approaches that are suitable specifically for technology teams. Here, we\u2019re going to drill down into one of the key aspects of a DevOps approach: Resilience Engineering, and how psychological safety is a fundamental component of resilience.<\/span><\/p>\n

Resilience Engineering<\/span><\/a> is a field of study that emerged from cognitive system engineering in the early 2000s, largely in response to NASA events in 1999 and 2000, including the failure of the Mars Climate Orbiter. It is defined as “<\/span>The intrinsic ability of a system to adjust its functioning prior to, during, or following changes and disturbances, so that it can sustain required operations under both expected and unexpected conditions.<\/span><\/i>” Erik Hollnagel<\/span><\/p>\n

\"\"<\/p>\n

Resilience Engineering is the intentional engineering of a system (a sociotechnical system, such as a community,\u00a0 organisation, or nation) to anticipate, detect and respond to both external and internal changes, planned or unplanned, to the system itself and continue to operate whilst change occurs. <\/span><\/p>\n

Very little theory within this domain has been generated that doesn\u2019t emerge from studies of real work; Resilience Engineering exists within high-stakes domains such as aviation, construction, surgery, military agencies and law enforcement and is becoming more visible in DevOps and Digital Transformation.<\/span><\/p>\n

There is a difference between robustness and resilience engineering,\u00a0 as described by David Woods, Professor, Integrated Systems Engineering Faculty, Ohio State University. Technological measures such as autoscaling, failovers, retries and queues, for example, only really contribute to robustness<\/strong>, not resilience:<\/span><\/p>\n