Policies are necessary and valuable… up to a point. This week, Business Technology’s resident U.S. blogger Keil Hubert explores why companies tend to leave obsolete and ineffective polices in place even though they’ve outlived their usefulness.
Policies are peculiar beasts.
Laws, we understand – when the government passes a new law, we understand the logical consequences of disobeying associated with it. Depending on how strongly the government feels about the subject, there may be fines, jail time, forfeiture of one’s property, and so on. We can make rational decisions about the risk-versus-reward equation and elect to follow or to break the law. Small fine? Accept it as the tax one pays for. Large fine? Maybe risk it only when the conditions for getting caught are very low, or when faithfully obeying the law will result in great harm. Further, we understand the concept that laws are imposed on us – hopefully with our knowledge and consent – in order to help everyone get along with a minimum of disruptive drama. There are exceptions, however; for every law (say, murder) there are unique circumstances where punishment doesn’t necessarily apply (say, self-defense).
Policies aren’t laws. Defined simply, policies are ‘deliberate systems of principles’ intended to ‘guide decisions and achieve rational outcomes’. They’re instructions that a company writes for itself on how the company’s key decision-makers want something to get done – often, done in a very specific way. Small companies tend to have very few (if any) formal, written policies; global enterprises tend to have far too many. The larger that a company gets, the more policies it tends to generate, like barnacles collecting on a ship’s hull. I chose the nautical analogy specifically, because policy build up (like barnacle accumulation) tends to make the ship of commerce move increasing slower over time until it loses its ability to manoeuver like its smaller, faster competitors. It also takes more effort to get underway from a dead stop, and consumes more energy to keep moving.
The thing is, policies are often necessary tools for setting standards of behaviour within a company, for defining the company’s stance on activities (both mandatory and forbidden), and for clarifying the top leaders’ intent. Companies create policies to comply with laws (like Equal Opportunity hiring), to preemptively defend themselves against future legal vulnerability, and to optimize teams’ responses to common situations. Even when they’re only implemented as a public statement of compliance, they do add value.
A well-crafted policy document isn’t a law – that is, the rozzers won’t arrest you for failing to book a meeting room through a particular website – but it can justify the application of certain administrative measures. You can be admonished, disciplined, suspended, or even terminated for willfully failing to abide by a company policy document. That attribute alone makes it imperative that policy writers craft their products precisely, clearly, and unambiguously. When it comes to depriving a worker of his or her livelihood, you’d better be sure that the punishment is proportional to the misconduct.
Policy accumulation is a natural byproduct of growth, right alongside slow decision-making, poor internal communication, and huge tax liabilities. That being said, there’s nothing inherently morally wrong with a company maintaining lots of policy documents… so long as they continue to serve a viable business purpose. All too often, policies get written to mitigate a certain known risk and then continue to affect people indefinitely through sheer inertia – still imposed, long after the conditions that gave rise to the original risk have made the policy irrelevant, or even counterproductive. Old, pointless policies are often grating; annoying employees without actually solving anything. So why allow useless policy ghosts continue to haunt the business?
Organizational psychologist Dr Shelia Keegan discussed this phenomena in her new book ‘The Psychology of Fear in Organizations’ and put some of the blame for shambling, undead policies squarely on fear. On page 80, she wrote:
‘To an extent we feel comfortable with regulations. They make us feel safe. We know our place and we can gauge our performance. But what happens when control becomes out of control, when meeting targets becomes the goal rather than fulfilling the task itself? When the desire to control is excessive for the needs of the task, it is worth questioning our motives for imposing these controls and perhaps heeding the warning signs. The need for control should be proportionate to the task in hand. Where we find high levels of control of systems, protocols and restrictive behaviours, which are disproportionate to need, we have to ask, “Is this control necessary or is it a symptom of a generalized level of fear – and our attempts to control this fear?” Over-control is one of the most obvious symptoms of fear in the workplace.’ [1]
In a rational organisation, an obsolete or malfunctioning policy would either be overhauled (and, thereby, made to work again) or would be scrapped. There’s no business value to be gained in leaving a worthless rule in-play that doesn’t achieve it’s desired objective. If anything, having a rule on the books that people clearly don’t follow (either because they can’t, or because no one cares to enforce it) breeds a culture of contempt for all policies. After all, if you can ignore one ‘mandatory’ directive, then you can probably ignore any of them. That sort of thinking can evolve into an audit and compliance nightmare.
That’s why I agree with the good doctor: I’ve wasted hundreds of hours of my professional life arguing against obsolete, abandoned and counter-productive policies, regulations, procedures, mandates and other control documents that had all outlived their usefulness. Most of those were still in-play in their owning organisation because the powers-that-be holding authority over the appropriate process(es) were afraid – afraid of exposure, nine times in ten. That is, afraid of being blamed by someone higher up in the company for having failed to adequately prevent in the present a bad outcome in the future. A published policy document is a bureaucratic and ablative shield that deflects the blame arrows when things go poorly… even when the policy itself is neither functional nor enforceable. The mere fact that it exists is often enough protection to save the owner from taking the full brunt of responsibility. Therefore, there’s a hardwired incentive for people in vulnerable positions or in chaotic environments (or both) to take shelter behind any and every scrap of administrative protection that they can find.
This is entirely in keeping with human nature. During the first years of America’s invasion of Iraq, lots of US military vehicles were sent into battle that had never been intended to take or to survive enemy fire. The 1980s vintage High Mobility Multipurpose Wheeled Vehicle [2] made by AM General had been deliberately designed with no armour, since it’s role was to be a light, off-road, utility truck that was meant to operate well behind the front lines – not to serve as an armoured car in an urban counterinsurgency. When soldiers in Iraw started taking fire in their HMMWVs, they raided junkyards for scrap metal in order to improvise some semblance of protection on their vehicles. It wasn’t a terribly effective solution since it weighed the light trucks down horribly, but it might help save a soldier’s life. Therefore, it was worth trying. Replace the words ‘soldier’ with ‘manager’, and ‘scrap metal’ with ‘policy document’ and the exact same mentality applies: it may be inefficient and sub-optimal, but it’s better than nothing when things go to crap.
It shouldn’t be that way. Remember that a policy is only supposed to ‘guide decisions and achieve rational outcomes’. Nowhere in the standard definition does it mention ‘shield vulnerable managers from career-ending blowback’. Unfortunately, that’s exactly what policies are used for more often than not. So, we need to work with policies as they are, and not just how they should function in a perfect world.
Therefore, we can approach policy creation in one of two ways, then: we can either attempt to write perfect control measures that account for every possible contingency and theoretical variation [3] or we can deliberately scope our control measures to cover the most common conditions, and then build in a pragmatic escape clause for line leaders, giving them the authority to deviate from the published standard when real life gets too weird for what we wrote. I’m a firm believer in going with option two, especially since I’ve never been 100 per cent perfect at predicting the future.
When I talk about ‘scoping’ a policy document, I mean that a rugged and reliable plan shouldn’t attempt to mandate behaviour for more than about 80 per cent of the probable outcomes that are likely for a given scenario. Work out what the most common manifestations of the governed process will look like, test them, validate them, and then build a sound policy statement around performing the required steps in the optimal desired manner. That then becomes the main body of the policy. For example, a corporate policy regarding control of visitors inside the workplace might read:
‘In order to protect sensitive company and customer information, only company employees and authorized guests are allowed pass the security station in the lobby into the restricted parts of the building. Guests must be escorted by their sponsor at all times, and must depart when their business is concluded.’
That’s a straightforward statement of intent: upper management does not want random people walking through the building and seeing, hearing, or otherwise getting ahold of restricted information. The control measure – approved and escorted visitors with official business are the only authorized outsiders – addresses the basic principles.
The next part of the policy needs to clarify common exceptions to the standard. These are often conditions that are understood, have been argued over already, and have an acceptable solution ready to implement. In our visitor example, a standard exception might be:
‘When management declares a “open house” event or conducts our annual family picnic, invited guests will be allowed to visit the common areas and cubicle farms on each floor, but only after management has ensured that all sensitive information has been hidden or otherwise secured.’
Since these events are common occurrences, it makes sense to spell out a special protocol to accommodate the special circumstances. The next part of the policy is – I think – the most important part. That’s the deviation authority passage:
‘For all unique circumstances not otherwise mentioned in this policy, the first manager in the supervisor chain always has the assumed authority to deviate from these protocols in accordance with his or her best judgment and with the principles of this policy document. The manager who chooses to deviate from the standard process takes full and complete responsibility for his or her actions (and for any consequences that arise).’
That paragraph is the catch-all clause that properly (I believe) balances the organisation’s need for control with leaders’ need to improvise as situations manifest that can’t be addressed by a rigid set of pre-determined orders. It transfers the risk for failure (in large part) to the manger that elects to deviate from the safe and blessed standard. At the same time, it gives that manager the authority that he or she needs to deal with a situation that the framers of the policy never envisioned. That’s why we hire leaders in the first place – to lead!
I fervently believe that every policy document should have a standard deviation authority block in it. For low-risk, low-impact threats, empower the employee make a judgment call; for high-risk and/or high-impact threats, it’s okay to make someone higher up the management chain take responsibility for the decision. Just don’t restrict that delegated deviation authority to someone so high up I the food chain that it becomes effectively impossible to get an exception to the bloody policy! That sort of tight-fisted, inflexible, rigid thinking only serves to cripple the organisation’s ability to swiftly respond to difficult events. It also communicates to the employees that they’re not trusted by the leaders of the organisation. That, in turn, corrodes employee morale and eviscerates esprit de corps.
As Dr Keegan said in Understanding Fear: ‘Emphasizing rules, rather than principles, encourages a mechanistic response.’ [4] The inescapable problem with mechanistic responses is that they’re often either ineffective or counterproductive in some iterations of the scenario that they were designed for; they not only fail to achieve their objective, they often make the situation worse. Mechanistic standards can’t possibly account for all possible variations on a given input. The world is messy, complicated, contradictory, confused, and (mostly) unpredictable. That’s why we invest power in our leaders at all echelons of our companies: to synthesize our company’s guiding principles with the unique needs of the moment in order to make the best decision possible given the totality of circumstances.
I urge everyone that has a voice in policy development for his or her company to consider adopting the deviation authority concept into their work. Keep your policies relevant, viable, and effective by building in an escape clause. If you fail to give your people some manoeuvre room to deal with the unexpected, they’ll eventually be left with only two choices when your policy runs out of relevancy: to either ignore it, or to follow it faithfully right over the edge of a (metaphorical) cliff. Neither of those outcomes does the business any long-term good.
[1] Emphasis added.
[2] Also known as the HMMWV, ‘hum-vee,’ or ‘hummer.’
[3] Good bloody luck with that.
[4] Page 87
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on twitter at @keilhubert.
You can buy his books on IT leadership and IT interviewing at the Amazon Kindle Store.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.
–
