Normalization of Deviance

BLUF: You must maintain standards in order to drive projects to the right place.

In January of 1986 Challenger launched and shortly after succumbed to an explosion.  It was later found that an O-ring caused the explosion and they later learned that it was a set culture to accept deviation from the norm.  All actions pointed to an almost certainty that Challenger was not going to make it.

Dr. Diane Vaughan wrote about this situation and coined the phrase normalization of deviance.   It is defined as “The gradual process through which unacceptable practice or standards become acceptable. As the deviant behavior is repeated without catastrophic results, it becomes the social norm for the organization.”

Normalization of deviance is a widely known problem in many areas, but most obviously in aviation because of the safety aspect that encircles the aviation industry.  You can accurately chart a timeline where safety violations occurred prior to a major safety accident that was either major damage to an aircraft or a person.

In software an example would be that you continuously let teams or teammates manually deploy out of cycle to fix bugs or when you let a merge occur without unit test(s).  You continuously let this occur and you eventually do it yourself without fixing or adjusting the problem.  Eventually you don’t notice the problems and every merge request continuously becomes worse along the way.

I recently admitted to exactly this problem.  I was allowing the team to commit merges without the proper merge request process where we need two developers to review the merge requests before a merge can occur and you also need to write unit tests.  I let these slide because the timeline was quickly approaching and for 2 months I didn’t adhere to the process.  When the deadline passed and we had some leeway in our timeline.  I recaged everyone’s expectations to know that they need to have 2 other teammates review the merge request and ensure that unit tests are written if needed.

While you are working through a project and if you are looking at team trends through after action reviews (AARs) or retros.  Plot the bad things that happened and track your team trends to find the violations that could create a damaging issue in the future.  Take the time to exercise on an issue that already occurred to see if you can find the precursor events that you could have changed before the event occurred.