Peter Waterhouse, Senior Strategist, CA Technologies, discusses the ‘normalisation of deviance’ phenomena among IT teams.
Regardless of whether you lead a start-up or work in an established business, we all have a tendency to accept dodgy behaviour. Even if outsiders see it as wrong, our IT teams are so accustomed to using it (without any adverse consequences) that it’s quickly established as ‘normal’ and accepted.
Studies into what’s commonly referred to as the ‘normalisation of deviance’ have been conducted in areas such healthcare and aerospace, with evidence showing that many serious errors and disasters occur because established standards have been bypassed and bad practices ‘normalised’.
While examining this phenomena is critical in the context of safety, it’s equally applicable in how we develop, secure and operate software applications. With the boundaries blurred between the digital and physical world, any adverse behaviour leading to security and reliability issues could have dire consequences for customers.
The DevOps movement, with its focus on collaboration across development and other IT functions, is now regarded as the best way of establishing the culture and environment needed to support fast and reliable software delivery.
In the healthcare sector, for example, studies illustrate seven factors that lead to a normalisation of deviance, all of which are IT relevant:
The rules are senseless and inefficient – in healthcare, accidents occur when practitioners disable equipment warning systems because alarms are seen as distracting.
Knowledge is imperfect and uneven – employees might not know a rule exists, or they might be taught a practice not realising that it’s sub-optimal. In IT this persists because many new employees feel uncomfortable asking for help.
The work itself, along with new technology, can disrupt work behaviour – to support goals of more continuous software delivery, organisations are introducing many new technologies and methods – like microservices and containers. New work practices and learning demands may lead staff to poorly implement technology or use it to perform functions it was never designed for.
We’re breaking rules for the good of the business – staff may bypass rules and good practice when they’re incentivised on faster delivery times or delivering new functional software enhancements.
The rules don’t apply to us, trust us – autonomous agile teams are beneficial, but empowering them to select their own one-off tools or to bypass compliance policies can compromise programme objectives or lead to security breaches. Unfortunately in today’s fast-paced digital business, talented professionals often feel completely justified in playing the trust card.
Employees are afraid to speak up – violations become normal when employees stay silent. Poor software code, costly projects (and bad managers) have been tolerated for so many times due to people being afraid to speak up.
Leaders withhold or dilute findings on application problems – rather than present ugly news, many will distort the truth; presenting diluted or misleading information up the command chain. In IT this behaviour is easily normalised, especially if teams get away with reporting technical vanity metrics over business outcomes.
No sudden cultural reawakening in IT or liberal sprinkling of collaboration fairy dust will eliminate ingrained bad practices, but DevOps and lean thinking can help identify warning signals. This starts with leaders visualising the flow of value delivered by software applications, pinpointing all the bottlenecks and constraints impeding delivery.
As with anything involving people, the organisational and psychological barriers encouraging staff to break rules or for their colleagues to remain silent is where most attention should be focused.
