Ok, but apart from just noticing it, how can I/we combat the normalization of deviance?
I don't see practical guidance on how to do it in the article? Do I just sit down and throw my arms in the air, and complain "oh, how things are going in a bad way"?
From https://news.ycombinator.com/item?id=21406452:
> One way to mitigate the "drift" is to have zero tolerance for deviation from procedure, but to also have a formal and rapid system for updating procedures, including explicitly temporary measures.
80% of the post mortems I’ve been in are caused by someone insisting on removing safety processes we had all agreed to. All you can do is get that shit in writing beforehand so someone is accountable, and resist the (reasonable) urge to yell I told you so afterwards because that will get you fired. Suggest that there needs to be process involved in changing established processes and then the lazy/unsafe way becomes more work.
Or to put it more in terms of Dekker and Rasmussen, there’s a gradient towards least effort and a gradient towards higher efficiency and that’s almost all there is to work with at a systems level. Safety/quality culture can’t really operate in terms of “look, this is the virtuous way you’re ignoring here!”
Mine haven’t been that high but once you’ve dialed in a process a lot of post mortems do come down to the Law of Unintended Consequences. We changed this and now that breaks. Usually not a straightforward cause and effect like you’re seeing.
I do spend time trying to combine or automate steps by other mechanisms though, so I am always on a team where the growth rate of the burden of the rules is a little flatter than they otherwise would be. So the rate at which people get fed up and start rallying to delete things may be a little lower for me than the mean.
Any easy distillation loses crucial tail frequencies. I read The Design of Everyday Things by Don Norman and Understanding Human Error by Sidney Dekker back to back and it seemed to me that a lot of this was:
1. Have ergonomic procedures
2. Measure usage
3. Treat compliance failure as a problem with the procedure
4. Treat 100% compliance as evidence of lack of reporting
5. Defence in depth
If you want quick heuristics for a blind man, listen for "if they had just", "oh we never", "a competent X would have". All are signs your tools and procedures have problems. You should expect to have many low-level compliance failures but they should be uncorrelated (i.e. same person should not be making all the mistakes, many people should not be making the same mistake).
I am not a professional in this field, however, so take this with a grain of salt as my understanding based off what I read.
You can’t generally change anything about this kind of culture unless you’re in charge of a large department, but it’s still worth understanding how it plays out because you’re going to be affected.
https://raw.githubusercontent.com/lorin/resilience-engineeri...
This one diagram neatly captures tension between infosec/devops/management/engineering/qa at most organizations. If you know who has the most power, how the executive suite evaluates liabilities, etc, you can guess which gradient has the most momentum, and maybe even start a countdown to disaster when deviance is too normalized for too long.
Anyway, grassroots “we need more tests” stuff can’t actually hurt, but other stakeholders can always make sure it won’t help. Safety/quality is an org responsibility, and it requires cooperation. Only someone who can hire/fire department heads can really create the necessary conditions. One of the biggest red flags is leadership that acts like it’s one group’s responsibility, because that’s such a naive POV that no one senior would really believe it, and most likely someone is about to be scapegoated.