If you work for a company of practically of any size and in any industry, it is quite a certainty that you will be expected to read and follow a considerable number of workplace policies (or management decrees). Many of those policies will have a very good reason to be in existence. It could be because there are legal requirements that staff must meet in their job, or simply because they reflect good common sense and best practices.
However, with the rare exception, most of these policies are written in the most tedious and unfriendly language possible. The result often is that staff can remain woefully unaware of key aspects of their role and unprepared to take the correct actions when the time comes. Staff regularly see these policies as something negative, restrictive and, even, something that needs to be actively opposed.
So, what do we often do, as managers, when we realise that a policy is not working? We rewrite it making exactly the same mistakes and we demand that all staff “read & understand” the policy. Surely, we are all aware the this is quite likely a pointless exercise doomed to failure and wasting valuable time (ours and our staff).
So, what can we do?
The Gamification of the Workplace
Playing games is probably the most natural way for humans to learn. This is how we learn as a child and it is one of the most effective ways for people to learn new skills and try out new things. This natural tendency to accept new concepts during play-time, is why the most effective training sessions are those that contain very interactive elements and why we are asked to role play. And why “Gamification” is such a trendy word in our Social Media-driven society.
So, next time you need to introduce a new policy or create a new procedure, think about how to keep that policy down to 1 single page and consider how you could create a “game” that helps enforce the policy or simply create the necessary behavioural habits that deliver what the policy is set out to achieve.
Example 1: Safe Workstations
Many companies have policies to ensure the secure handling of data assets. Some of the simple actions to deliver these may include things such as keeping a tidy desk, enforcing a new password at regular intervals or making sure you lock your screen when you leave your PC. This last one, was one that was completely ignored in a company I worked with in the past. In an open plan workspace, the information that could be gathered from unlocked PCs was a considerable risk and no threat from management managed to create that habit.
So, we turned the policy on its head and created a game.
Whenever a PC was found unlocked, staff were encouraged to use the offender’s email account to “announce” to the rest of the department the most embarrassing “admission” or “secret” they could think of. No rules and no limits enforced. (I would recommend creating a specific email list with all the relevant staff in it for this). The best “announcement” of the month was entitled to a very attractive reward (something like a £50 Amazon voucher does wonders). During the first few days of the “game” only the bravest went for it, but within a week everyone was in it and actively seeking “revenge” on whoever had embarrassed them just a few days before. Within 4 weeks the game was almost dead. Why? Because everyone was locking their machines to avoid further “admissions”.
So, with a bit of imagination and a simple game we managed to create the habit of locking the screen when people left their desk and finally met the policy goals.
Example 2: Quality checks of software code
I have not implemented this one (yet), but it was brainstormed with developers in a company. However, I am confident it could work quite well (with tweaks).
If you have ever been involved with a team of (proud) software developers, you will know that some of them will be extremely protective of their code & negative towards any initiative that makes them spend time checking the quality of the code they have written. Sometimes, this is due to a lack of confidence (even fear of failure) on their part or quite the opposite (“I am an uber-developer and my code is perfect” anyone?). Whichever way, more and more teams are adopting pair programming as a means to deliver software quality. I am very fond of pair programming, but many companies, managers and individual actively discourage this. So, while you work behind the scenes to get pair programming going, we have to turn to traditional methods such as code reviews and, let’s be frank, there is little fun in doing those.
So, in this case we discuss creating a weekly code-busters session where the team would sit around a projector enjoying a few snack and soft drinks while discussing the strong points and weaknesses of the code under review. People volunteering to get their code reviewed would gain points. The more robust the code was, the more point they would accrue. Similarly, those finding minor issues would accrue points, while a major discovery would hoard a significant treasure. At regular intervals , those commanding more points would get significant rewards. Of course, this was never put in practice, so I would expect to need to tweak the setup during the early days of the process, but it was rather interesting to see the competitive side in some of the developers in the team coming through just as we were discussing the idea.
Ah! And remember to introduce bonus points for those “hidden” successes that happened while working as a pair.
Rules to create effective games
- Rule 1: Make it fun. If it is not fun people won’t bother.
- Rule 2: Bring out the competitive animal in us.Make it a challenge. Create positive feedback loops that encourage the game to sustain itself.
- Rule 3: Have a reward. Shopping vouchers work. Make them public and give them out at a team or departmental meeting.
- Rule 4: Involve your staff. Coming up with the game or refining it is a lot of fun in itself. Get the team involved in the process and you will see the extra buy-in and, even, how morale levels and performance are increased elsewhere.
- Rule 5: Don’t be afraid to try new things. If a game is not working, see if you can tweak it to improve it. If you can’t then try to learn why and simply drop it.
- Rule 6: No ivory towers. Policies are for everyone, so lead from the front. If you create a game, make sure management are fully immerse. If you can’t be bothered, your staff will notice it and they will lose interest themselves.
That’s about it.
Give it a go and share your experiences. What works? What doesn’t? Also, if you don’t agree with this, feel free to let me know. I’d be happy to hear and learn from you.