Beatings Will Continue Until Morale Improves

In 1789, a famous mutiny occurred on the HMS Bounty, a British Royal Navy vessel. A band of sailors led by acting‐Lieutenant Fletcher Christian seized control of the ship from Captain William Bligh, who was set adrift with eighteen of his loyal crew. The story has been made into a musical, several movies, and countless books.

A common feature of the story's fictionalised versions is an order Bligh is said to have given to his men. Apparently, he told them, “Beatings will continue until morale improves.” There is no evidence that Bligh actually said this. Nor is there any evidence that he also said, “Never let the truth stand in the way of a good anecdote.”

As a memorable quote and “last straw” plot device to explain a mutiny, “beatings will continue” works really well. As an actual order, it makes no sense whatsoever. Administering beatings will not achieve the desired outcome of improved morale.

Outcome

What the fictional Bligh failed to understand was that engaging human beings isn't a matter of mandating or forcing it. As anyone who has experienced a corporate awayday with an element of “enforced fun” will appreciate, we can't force people to feel a particular way; they either do or they don't.

Of course, they can pretend to be having fun. Just as they can pretend to be following rules. But since we're interested in people actually doing what we want them to and not just going through the motions – particularly when no one is watching – we need to understand the underlying drivers. This is where Rule Number One comes in:

Compliance is an outcome, not a process.

As we saw in earlier chapters, it is easy to confuse the process we use to deliver a desired organisational outcome with that outcome. To put it another way, we mustn't confuse the “job” with the “tool” we use.

compliance Is Not Compliance

Since I'm going to use the “c” word a lot in these rules – “compliance”, that is! – it's probably worth me reiterating what I explained in the definitions in an earlier chapter. Not for you, obviously, but for those readers who might have somehow managed to miss those pages!

When I refer to “small c” compliance in this book, I'm not talking about big “c” Compliance, the function. What I mean by “small c” compliance is an outcome: getting our employees to do what we want. That outcome might be to comply with a policy, or it might be to do something that has absolutely nothing to do with regulation, such as responding to an employee survey or using the office stairs as opposed to the elevator.

As someone who has worked in “big C” Compliance, it might surprise you to learn that I think the word is awful. It's one of the worst pieces of branding ever! If you wanted to signal that you were dull, bureaucratic, and officious, you'd choose a word like Compliance. And then you'd add the suffix “Officer”. It's probably the only time the word “officer” makes something sound worse! That's not a criticism of the function, by the way, it's the branding I can't stand.

The reason I need to explain the difference between Compliance and compliance isn't just to avoid confusing you. It goes to the heart of this rule. This means I can write one of the most confusing sentences ever: While Compliance is a process, compliance is an outcome.

Look Where You Want to Go

If like me, you ride motorbikes, then you'll be familiar with a very simple rule. You learn it early in your riding career, ideally by being taught it rather than from experience! If you're riding around a bend, then the one thing you shouldn't do is look at the bend. Instead, you need to look where you want to go. Otherwise, you risk crashing into the thing you're fixating on avoiding. It's counter‐intuitive, but as I can attest from personal experience, highly effective.

Yet, when it comes to compliance, we tend to do the opposite. Rather than thinking about the outcome we're looking to achieve, we focus more on the frameworks, processes, and policies we've implemented to get us there. This feels logical, and there are valid reasons why this happens. However, as we'll see, if we don't look at the outcome, we will rely on processes that won't always do what we want. In motorcycling terms, we're looking at the bend, not where we want to go.

The Business of Influencing Human Decision‐Making

We tend to focus on process when we think about compliance because we understandably look at the challenge through an organisational lens. Since we aim to have the organisation be compliant, the logical solution is to have a Compliance function that ensures that can happen. They use frameworks, controls, policies, and rules to meet that objective.

However, organisations cannot be compliant of their own accord. You can't tell a brand, building, or legal entity what to do and expect a coherent response. The employees within the organisation will determine whether or not the organisation is compliant. The business of Compliance is, therefore, to influence human decision‐making of the people within the organisation. If they succeed in that mission, the organisation is compliant. If they don't, it isn't.

Yet, more often than not, that isn't how Compliance functions are positioned or perceived. Ask the average employee what comes to mind when they hear the word “Compliance”, and you're unlikely to get an enthusiastic response. If you're lucky, they'll say something about “rules” or “regulations”. If you're unlucky, you'll get “business prevention unit”. If you're really unfortunate, it'll be something I can't print in this book. You're unlikely to hear a word like “human”.

I'm not suggesting that they need to win a popularity contest. Still, if we genuinely want to ensure that an organisation is compliant, we must ensure that Compliance has the mandate, skills, and resources to influence employee decision‐making. Historically, most organisations haven't adopted that approach, which has meant that the processes designed to deliver compliance aren't thinking about influencing people.

The Human Algorithm Is Not Logical

As we saw from the traditional toolkit and the “beatings will continue” story, we often implicitly assume a linear relationship between the process we've put in place and the outcome we're looking to achieve. That makes perfect sense in environments with predictable dynamics. Suppose we're designing engineering processes that rely on the laws of Newtonian physics. Those laws will always apply in that case, and we know that following the procedure will deliver the outcome we're looking for.

Yet, as we've seen in the earlier chapters, human decision‐making isn't logical. If, for example, we write something in a policy, we might logically expect our employees to read, understand, and comply with it. But, in reality, we know that might not happen for various reasons. People can be forgetful, negligent, in a hurry, or any number of other things that can mean they don't always do logical things. That's before we think about people being creative in terms of how they interpret rules. Equally, people writing rules don't always get them right. They're fallible and miss things as much as the people for whom they write the rules.

We also need to remember a simple fact. The average employee isn't interested in Compliance. If they were, they'd be working in the Compliance function. What they are interested in is compliance. Most people want to turn up to work and do a good job, not break any rules, and do the right thing. The role of Compliance is, therefore, to help them achieve that. For that to happen requires us to humanize our rules.