Sidney Dekker; Scientist, aviator & story teller

A couple of years ago during the 2017 DevOps Enterprise Summit professor Sidney Dekker took the stage. I was intrigued by the title of his talk : “The pursuit of success & drifting into failure”. He unveiled himself as scientist and an engaging story teller, who’s written a lot of books and made a movie. Through his scientific understanding of the World, he is able to distill essential messages from the field of safety science and convey these in layman’s terms. Through this talk I first discovered the impact this has on DevOps teams and getting work done. Let’s dig into a few details.

Three simple statements

As you may have seen in the video link above, professor Dekker presents three seemingly simple but profound statements:

• “Anything! in your organization that creates downward pressure on honesty, disclosure, openness and learning is bad for your business”.
• “Any field of work has its own sweet spot with regards to rules and standardization”
• “The counting and tabulating of negative events, as if they are predictive of a big bad event over the horizon, is an illusion”

For me, this immediately got the mind going. I strongly associate these statements with some of the behavior seen in large enterprises. Especially when these companies are trying to move the needle on their DevOps journey, but seemingly are unable to progress.

Before I had seen this talk I couldn’t articulate the nature of the symptoms I’d seen or point out potential causes. Just looking at these three statements already gives tremendous insight and helps me understand what I’m looking at with regards to these companies hitting a plateau. It also raised my interest for diving deeper into the field of safety science. Not in order to become a scientist, but to help me better understand the subject matter and improve my ability to address/describe some of the challenges I will encounter.

Eye opener

To continue my journey I dove into a couple of books, as you may have noticed, Dekker has written quite a few. When reading “Foundations of safety science” I stumbled on a remarkable assumption I held. I had never properly understood why we have safety regulations in the first place. It turns out it’s not to protect the workers, but to protect the production line. That may seem like a trivial difference, but when you think of the implications that has, you’ll see the emergence of a landscape that is built on human collateral supporting the economic function though the work they perform.

Does it help?

Given the previous statements, do all rules and regulations really help us get things done in a safer way with better outcomes? Think of all the rules you see in place and let your gut feeling evaluate whether or not that helps the people in your organization get things done. Make a list of these, we’re going to need that later.

Safety differently

There is an assumption that “Excellent outcomes equal zero accidents, mishaps and errors or whatever the KPI might be”. It turns out that this is actually is an invitation for a big problem or disaster to happen. The crux behind this is found in the accounting of these mishaps, as presented in the third statement by Dekker. If organizations are not willing to be open and honest about these incidents through their disclosure, illusions are being created. This leads to a false sense of safety so to speak. Statistically significant for this is the inverse correlation between the number of reported incidents and things actually going badly wrong.

To clarify that, if there are more reports on incidents, the company is more likely to have a better safety record (i.e. less non-fatal accidents and less critical incidents). Now think about how counter-intuitive that feels and how it may help you identify something to change in your company.

Focus on how success is created!

How to counter all that accounting and emphasis on “negative experiences” and mistakes?

The team of Professor Dekker was able to study: “Why an operation goes right instead of wrong?”. It turns out that exactly that operations that went right, the same errors and mistakes we’re made, as if you we’re looking at the operations that went wrong. The key difference between these is in the presence of so called “positive capacities” not in the absence of the “negatives”.

With positive capacities Dekker refers to the things people bring to a situation:

• The ability to say stop!
• Not taking past success as guarantee for a positive outcome
• Diversity of opinion/dissent
• Keeping discussions on risk alive

I’ve looked at that list and see quite a few things that are missing in the things people are able and allowed to bring to work in these large corporations. So much is hidden behind process and bureaucracy. The puzzle is to figure out what we need to do to enable those capacities.

How stuff gets done, despite the constraints

There is on many occasions a big difference between “how work is described to be done” and “how work actually gets done”. How work is described, specifies the process and rules to be followed to accomplish a job according to the approved standards and guidelines. However a guiding principle to how “work is actually done” is that it follows the path of least resistance. The motivation for this originates from the desire to become more effective, and for example to remove wait times for hand-offs. Another difference originates from the people doing the work, changing the order of actions or do things in parallel or even preempt decision they await assuming “it will be all right”. This also boils down to having smart people doing the work, but you can see the friction that creates with the paper tiger.

Enterprises, DevOps and compliance

The difference between “as designed” vs. “as done” applies very strong to process driven companies, especially enterprises. For enterprises one of the reasons to be process oriented is to demonstrate compliance. If we “just follow these steps then the auditors are happy”. If you want to read a bit more on the monetization of bureaucracy , have a read of Sidney Dekker’s book “Compliance capitalism” ;-) Except that this rigidity creates a world where “doing work”, especially completing something often and early, is very hard and mind numbing. Besides creating a uninspiring environment to work in it also creates the false sense of safety for the leadership and the people doing the work because the process is not precisely how things get done.

DevOps in the enterprise

Where such a burden meets “DevOps in the enterprise” is in all kinds of rules and regulations around building and releasing a piece of software to production. You can guess that process heavy compliance breaks all attempts to achieve flow by introduction of hand-overs, approvals and hand-holding. This overhead by nature causes the creation of large batches of change, which in turn create high-risk for failure/error.

As professor Dekker has indicated, the accounting of negative things leads to more regulation. So that outcome will result in even more stringent checks and inspections because «something has gone wrong». This is the kind of “death spiral” for initiatives aimed at generating flow. As we know, with good intensions, aimed at relieving the process burden, and aimed at improving the environment to work in, we don’t always get a better outcome. Shame.

What needs to change?

Going back to the second statement by professor Dekker : “Any field of work has its own sweet spot of with regards to rules and standardization”. In many enterprises we then seem to be quite a way away from the sweet spot. To get closer to that, a sensible thing I can think of is to reassess the way compliance is achieved. Let me be clear, I think to a large extent having compliance needs in place, like for example GDPR or environmental regulations, are a good thing. Especially for large systems and organizations to create accountability towards a broader society and the wellbeing of our planet.

A change in approach will entail having to challenge auditors on the way we can achieve compliance by pushing the boundaries of the described standards and challenging the applicability of those (old) standards to a new context. That is not going to be easy, and will require a lot of courage and tenacity. But it is a valuable investment of our time since it potentially will help to achieve flow (or at least get a few steps closer to attaining that). Where this is obvious is in for example applying “on-prem” data processing standards to a cloud based environment. The way of working with cloud is radically different, especially to be effective and bring a good return on investment. A lot of reasoning in the audit realm still seems to stem from the good old “on-prem, everything is located in your basement” times and is extrapolated to “someone elses data center”. That doesn’t match with modern IT landscape and expectations, especially in situations where we are now building hybrid distributed systems. Again this is where we need to challenge the standards and how auditors perceive compliance with them.

Setting new standards

A way to challenge is also to create new standards. In those we need to look at what brings successful outcomes and use that as guiding principles for defining new compliant ways of working. That way we can remove the unnecessary friction where possible and for instance we can introduce aspects like trust on people, maximize automation and aim on the ability to learn and recover fast.

In the mean time

Achieving the definition and ratification of these new to be created standards is of course not the work of a few individuals, but the effort of an entire industry pulling together. As we’ve seen how slow these processes are, that will take a while, if not a decade or two. So in the mean time the thing I’d like to advocate is for individuals to stand up, bring their positive capacity to the game and challenge the status quo. By expressing feedback consistently, start discussions we can in our individual cases create room to move. This is necessary to get the ball rolling and at the scale of large organizations create large savings in effort, coincidentally creating a better environment to work in.

Thanks Professor Sidney Dekker

Sometimes you just get lucky and learn so much from a person you didn’t knew existed before. In this case it has unlearned me a few assumption I’ve held and provided a lot of new insights. Let me express a huge “Thank you!” to you professor Sidney Dekker on this occasion. It’s been a great learning experience and I hope you keep telling your inspiring stories.