What is normalisation of deviance?
Engineering culture and software practice
Normalisation of deviance is the gradual process by which unsafe practices come to be treated as normal because they have not yet caused harm. Warning signs are quietly reinterpreted as acceptable until, after a long incubation, a serious failure arrives. The sociologist Diane Vaughan named the pattern in her 1996 study of the Challenger launch decision, and the Columbia Accident Investigation Board applied it to NASA again in 2003.
What this means
Every organisation has rules, standards and controls. Normalisation of deviance is what happens when people drift away from those standards a little at a time, get away with it, and slowly come to see the drift as perfectly fine. Nothing broke last time, so the shortcut becomes the new normal, and the next shortcut is measured against that. The danger is invisible from the inside, because the people involved are not being careless; they are following what has become ordinary practice.
Diane Vaughan coined the phrase to explain something that puzzled outsiders about the 1986 Challenger disaster. Her argument was that this was not a story of villains knowingly breaking rules under pressure. It was structural and incremental: engineers and managers repeatedly saw evidence that a component was behaving oddly, explained it away, and folded the anomaly into the definition of acceptable risk.
The pattern has a name because it is counter-intuitive and recurring. Once you can name it, you can look for it, because the whole problem is that the organisation has stopped noticing what it has quietly accepted.
Why it matters
Most organisations that depend on software will recognise the phrase "we have always done it that way." Ignored monitoring alerts, expired certificates left unrenewed, passwords shared "just for now", code reviews skipped when things are busy, backups never actually tested: each of these usually started as a one-off that caused no harm and then hardened into routine. The absence of a disaster is treated as proof of safety, when it may only be luck.
Artificial intelligence has given the pattern new territory. When a team ships output from an AI assistant without checking it because the last ten times were fine, that is normalisation of deviance in motion. The check was a control; quietly dropping it because nothing went wrong is exactly the drift Vaughan described.
For a leader, this reframes what audit findings and near-misses are really pointing at. A finding that a control is not being followed is rarely about one lazy person. It is usually a signal that the organisation has renegotiated its own standard without deciding to. The practical stakes are that the failure, when it comes, tends to be sudden and severe, because the warning signs were reclassified as normal for years beforehand.
Barry Turner's earlier work on how disasters build up over a long, unnoticed incubation period gives the same warning: the trouble accumulates quietly, out of full view, long before anything visible happens.
How it works
Where the term came from
The phrase comes from Diane Vaughan, professor of sociology at Columbia University, in her 1996 book The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA, published by the University of Chicago Press. Drawing on a decade of study of NASA documents, she rejected the popular account that managers had calculatedly gambled with safety under schedule pressure. Instead she found that NASA insiders, repeatedly faced with evidence that something was wrong, normalised the deviance so that it became acceptable to them. O-ring damage that should have been a danger signal was reinterpreted, launch after launch, as within an expected range.
The concept was applied to NASA a second time in 2003. Vaughan sat on the Columbia Accident Investigation Board, and the Board's report devotes a chapter, "History as Cause", to the argument, with a section headed "Failures of Foresight: Two Decision Histories and the Normalization of Deviance". The Board concluded that organisational and cultural causes weighed as heavily as the physical cause. There is an honest debate about attribution: Barry Turner's 1978 book Man-Made Disasters had already set out the idea of a long "incubation period" of unnoticed warning signs, and some scholars argue his foundational contribution is under-acknowledged.
The mechanism, step by step
The drift follows a recognisable sequence. A standard exists. Someone deviates from it, usually for a sensible-sounding reason such as time or workload. No harm follows. The deviation is repeated, and because the feared consequence has not appeared, the risk is judged to be lower than the rule implied. The new, weaker practice becomes the reference point, and the next deviation is measured against it rather than against the original standard. Over time the gap between what should happen and what actually happens grows wide, but no single step felt reckless.
How it looks in software and AI operations
In healthcare, John Banja's 2010 paper in Business Horizons showed how even egregious violations of practice standards can become normalised across a whole team. The same holds in software. A flaky alert that fires too often gets muted, then ignored, then deleted. A manual deployment step that is meant to include a check gets shortened because the check always passed. A model that once had a human reviewing its output loses that reviewer quietly as volumes rise. None of these decisions is minuted; the standard erodes by practice, not by policy.
How experienced teams handle it
Mature teams treat the absence of accidents with suspicion rather than comfort. They run deliberate deviance audits, comparing what the written standard says with what people actually do, and treat any gap as information rather than as a disciplinary matter. They make near-miss reporting easy and rewarded, because near-misses are the incubation-period signals made visible. And they periodically ask a simple question in plain language: what have we quietly come to accept that we would once have escalated?
Examples
Consider a professional services firm whose client portal uses a security certificate that must be renewed each year. The first year it lapses by a day and nothing happens, so the reminder is downgraded. Within three years the renewal is nobody's job, the portal briefly goes dark during a client deadline, and the post-incident review finds that everyone assumed someone else was watching. The certificate was never the point; the eroded standard was. This is an illustrative scenario, not a specific organisation.
A small charity shares a single login for its donations dashboard because setting up individual accounts felt like overkill for four trusted staff. Nobody misuses it, so the practice spreads to the finance system too. When a volunteer leaves under a cloud, the charity cannot tell what that person did or revoke only their access. The shortcut had been normal for so long that no one remembered it had once been a conscious risk.
A software team of eight mutes a noisy monitoring alert during a busy launch and never unmutes it. Separately, they begin shipping copy drafted by an AI assistant without the review step they had agreed, because early samples were good. Months later a factual error reaches customers and the muted alert would have caught a related fault. Two independent deviations, each individually harmless, combined into a visible failure.
Common misunderstandings
The first misconception is that normalisation of deviance means people are cutting corners on purpose. Vaughan's whole point is the opposite: the process is structural and incremental, and the people involved usually believe they are behaving reasonably by the standard that now prevails.
The second is that it is the same thing as a blameless post-mortem. It is not. A blameless post-mortem is a review ritual held after an incident, whereas normalisation of deviance is a failure mechanism in how an organisation perceives risk over time, unlike a meeting that happens once at the end. The post-mortem is one place you might detect the drift; it is not the drift itself.
The third is that every shortcut is deviance. Rather, deviance is specifically a drift away from a standard that exists for a reason, dressed up as acceptable. Sensible adaptation to genuinely changed circumstances is not the same as quietly abandoning a control.
The fourth is that this is a NASA problem or a big-organisation problem. It appears in teams of any size; the smaller the team, the fewer the people who might notice.
The fifth is that naming it after the fact proves the organisation was negligent. That is hindsight bias, and Vaughan warned against reading obvious villainy backwards into decisions that looked reasonable at the time.
Risks and boundaries
The concept can be over-applied. After any failure it is tempting to label every prior decision as normalised deviance, which is hindsight bias wearing academic clothes. Not every accepted practice is a latent disaster, and treating every deviation from an ideal as dangerous will exhaust a team and drown the signals that matter.
There is also a genuine scholarly debate about origins and even about the model itself. Turner's incubation-period work predates Vaughan, and Charles Perrow's separate "normal accidents" argument holds that some complex systems fail unpredictably regardless of culture. The honest position is that these are complementary lenses, not a single settled law. Used well, the idea helps a leader ask better questions; used lazily, it becomes a label for blaming people after the fact, which is exactly what a just culture and a blameless review are meant to prevent.
What to do next
Start by asking your teams what they have stopped doing that they used to do, and why. The answers surface drift faster than any audit, because the people doing the work already know where the standards have quietly moved.
Make near-misses safe to report and genuinely welcome them. A near-miss is a free warning from the incubation period; a culture that punishes the messenger will simply stop hearing them.
Run occasional deviance checks that compare the written procedure with the observed practice for a handful of important controls, treating any gap as a subject for curiosity, not discipline. The UK Health and Safety Executive's guidance on safety culture is a useful, plain reference point for how leadership shapes whether standards hold.
Finally, pair this with a just culture and a blameless review habit, so that when drift is found, people are willing to say so rather than hide it.
FAQs
Who coined the term normalisation of deviance?
The sociologist Diane Vaughan, in her 1996 book about the Challenger launch decision, published by the University of Chicago Press.
Is normalisation of deviance the same as complacency?
It overlaps but is more specific. It describes a measurable drift away from a defined standard that comes to be seen as acceptable, not just a general loss of attention.
How is it different from a blameless post-mortem?
The post-mortem is a review held after an incident. Normalisation of deviance is the slow failure mechanism a post-mortem might uncover.
Does it only happen in high-risk industries?
No. It appears anywhere standards exist and can quietly erode, including small software teams and AI-assisted work.
How can I spot it early?
Look for muted alerts, skipped checks, and the phrase "we always do it this way", and make near-miss reporting easy and welcome.
Is every shortcut an example of it?
No. Deviance is drift from a standard that exists for a reason. Reasonable adaptation to changed circumstances is different.
How does it relate to AI output?
Dropping a human check because past AI output was fine is a classic case of the control eroding by practice.