Normalization of Deviance: What to do when human nature collides with procedures in the workplace.

Curated by: Sergio A. Martínez

It’s easy to point a finger at the culprit, right? That truck was way too heavy for this bridge, so we need to build sturdier bridges and think of a system that checks if a truck has the appropriate weight before crossing. Maybe even instill punishments and fines for people going over this limit. Easy stuff. Well, if that’s the case, then nothing was learned from this disaster. It will happen again in the future.

This is normalization of deviance. Simply put, it’s when people become so accustomed to seeing certain things done wrong that they no longer register as problems, but instead as the way “things work”. And they do work, until the day they don’t: catastrophic failures like a bridge collapsing are seldom the result of a single, unavoidable act of God, but instead the accumulation of small problems that one day reach a breaking point.  And normalization of deviance is a huge problem in the software development industry. 

However, how exactly does the normalization of deviance work, how does it affect software development, and what could be the steps to mitigate, or outright eliminate, the risks it presents?

Bending the rules (until they break)

Software and civil engineering are not that different, at least when it comes to the complexity and precision needed to build things. After all, engineering of any kind is the art of finding solutions that work under stress: creating stuff that works reliably, no matter who is using it. So, no matter if you work with code or concrete, the process is roughly the same: you need to take into account every single situation that the design demands. And thus, both disciplines also tend to have very similar problems, with the normalization of deviance being one of them.

Let’s go back to our bridge example: what was the actual problem? The truck was way too heavy to safely cross that bridge, for sure. But why was such a truck trying to cross it in the first place? Because simply put, it was a normal thing to happen, and if that sounds like a contradiction, you would be right. After all, the normalization of deviance is a lesson in human nature.

People like to bend the rules. That’s what we do. Intellectually, we know rules are meant to keep things working properly, but rigidity is not our strong suit as a species. In the words of veteran programmer Foone Turing: “We always want to optimize. We want to do things cheaper, quicker, and more at once. And the thing is, most of the time going a little faster, a little hotter, that’s fine. Nothing goes wrong. Engineers always design with a safety margin, as we’ve learned the hard way that if you don’t, stuff goes wrong very fast. So going 110% as fast as the spec says? probably OK.”

So, you may see where this is going. In our bridge example, an interesting wrinkle is that the disaster didn’t happen right away, it was a full decade after the bridge was constructed. That’s the tricky thing with the normalization of deviance: it takes time to build up. It works through subtlety: if your bridge says that it has a limit of 25 tons, but you once drove a 30-ton truck through it and nothing happened, then the actual limit is higher, right? You can do it again. And if you do it enough times?

“You’ve been going 110% all the time. It’s worked out just fine. You’re doing great, no problems. You start to think of 110% as the new normal, and you think of it as just 100%. […] Then one day you’re running into 5 other problems and need to push something, well, maybe you do 120% today? After all, it’s basically just 10% of normal…”. That’s how you get a 40-ton trailer trying to cross a bridge rated way lower than that: someone drove through it with 35 tons of cargo, and nothing happened. 36 should be fine, right? Or 37, or 38, and so on. Bending the rules became so normal, without any immediate consequence, that it ceased to be wrong. Slowly, it became the standard, and a standard supported by bent rules is always a time bomb.

But how to avoid deviance?

In software development, the normalization of deviance can happen at every level. For example, at a product level, it’s not exactly unheard of to release software that is not fully tested, on the assumption that the bugs will be fixed in future releases, which can lead to serious problems, such as data loss or security vulnerabilities. At the development level, programmers can start to disregard code style conventions if they feel slowed down by them (there’s a deadline to meet after all), resulting in a codebase that is difficult to read and maintain. And at the security level, it’s often easier to just write down a password than wait half an hour for IT to reset your account if you forget it. In either case, the result is the same: an organization will start accumulating issues until something serious breaks one day.

However, diagnosing the normalization of deviance can be difficult because there’s no immediate feedback loop to it. The bridge probably doesn’t produce a loud cracking sound if you go a couple of pounds above the limit, or the code doesn’t stop working immediately if you deviate a little from a style convention, so implementing effective ways to detect when it’s happening, or to deter this kind of behavior, can be tricky.   

The aforementioned Twitter thread gives a great example of why: “Susan gets in trouble because she put a post-it note with her password on her monitor, and we had to sit through a boring security meeting about password security. So, people learned to put their passwords in their wallets and their phones.” Or in other words, maybe the systems we have in place provide the incentive to deviate from the rules in the first place, and having after-the-fact measures don’t do enough to stop the buildup of problems. In that case, it falls on the culture of an organization to take into account these possible challenges and take the steps necessary to avoid lowering standards as a normal practice. These four key points might help:

1. Rules are not forever. When it comes to technology, a year might as well be a decade in terms of advancement and innovation, so every procedure and workflow must be constantly reviewed to ensure “rule-bending” is not encouraged when certain parts lag behind, becoming obsolete or just ineffective. Revising and streamlining are always valuable skills for the leadership of any company to have, and giving people the power to always ask “why” could help avoid problems down the line.
2. Open communication is critical. In that same sense, the main danger of deviance is that it develops in secret. Effective project management means communicating effectively with people, making clear the purpose of every rule, and being open to opinions, suggestions, and discussions to ensure those rules are effective and followed. Also, promoting an environment where a developer can communicate when a rule must be broken for the good of a project is crucial, as it allows management to respond and control such changes. “This situation has happened to us in the past”, says Jesús Magaña, Senior Project Manager at Scio. “And this decision has never been taken lightly. The objective, after all, is reaching the finish line without compromising quality or performance. This ‘shortcut’ has to be done with the consent of the Project Manager and the client, keeping in mind the possible consequences of doing so.”  
3. Any change has to be clear and well-thought. The software sector is also ripe for new technologies, frameworks, languages, and tools to be implemented during development, but these changes are not trivial. If a new element is adopted within the development environment without proper measures (like clearly explaining the benefits and drawbacks of the new tool, giving people enough time to acclimate to change, being open to concerns, etc.), the risk of deviance grows.
4. A culture of collaboration, not politics. Probably the most common cause of normalization of deviance, many of these examples don’t happen in isolation. Humans are social beings that tend to form cliques and in-groups that cover for each other, which can happen at every level of the organization, and thus be the perfect place to brew deviance that could snowball into disaster. So, promoting collaboration, being lenient enough with consequences so people feel comfortable about speaking up, but not to the point that developers feel they can get away with anything, and frequently promoting people to mix and work together in different configurations might be the key. It all comes down to skilled leadership.

And knowing is half the battle

However, let’s not assume that these steps, although useful, are completely infallible when it comes to mitigating the normalization of deviance because this kind of behavior is simply human. We bend the rules when we know we shouldn’t, even at a personal level sometimes (“I’m on a diet, but this piece of cake shouldn’t be a problem, right?”), but that doesn’t mean that we cannot anticipate, learn, and improve at every opportunity. Understanding this is what separates good software organizations from the rest of them. After all, as Jesus Magaña tells us, “one of the values of the Agile Manifesto establishes that ‘people and interactions are above tools and processes’, which implies that a process doesn’t have to be a rigid path. Sometimes you need to veer off-course, and that’s not cheating. Let’s just keep in mind that, if everything is going well during development, a process is meant to help us to be consistent with the quality of our work.”

The Key Takeaways

• Normalization of deviance, of lowering standards over time, is always a risk in any industry, especially software development.
• Simply put, people are going to bend the rules when that benefits them because that’s simply human nature.
• The main danger is that this normalization is almost always invisible until too late, helping the build-up of issues and problems until a disaster occurs.
• It’s up to the management and culture of an organization to mitigate this deviance, which is virtually impossible to eliminate but can be avoided with the right approach to communication and collaboration.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!