Gamification is… tricky.

I love games, in general, and in all their forms. Chess. Videogames. Sports. Card games. Logic puzzles. Just absolutely love ‘em!

Games All The Way Down

Once upon a time, I graduated college with a degree in economics — a field that’s all about that sweet, sweet cost benefit analysis. I loved studying the field. It’s right there, smack-dab in the middle of my wheelhouse.

Being able to analyze options and actions to see their positive and negative outputs is important not only in playing games, but also in designing them. (It also makes me insufferable when it comes to talking about policy, but that’s a story for another time, perhaps.)

One of the core requirements that all students of economics go through is, at the very least, an introductory course on game theory. Now, game theory isn’t about playing games, really — you could really just call it “decision theory, but with multiple actors”. It’s about navigating a maze of options and discovering an equilibrium, or… finding that an equilibrium isn’t possible.

So, I studied game theory, like a good student. In game theory, you look at multiple actors, the “games” they are playing, and their “payoff matrices”. You start to see how, many times, the results of “the game” are fairly predictable. Humans are creatures of habit and least resistance — they go where the greatest payoff is for the least effort. We all like to think we are the outlier, but in reality… we aren’t.

(Well, unless you’re an outlier, I guess. But, uhh, anyway…)

The thing about introductory academic game theory is that your payouts are generally well-known. You don’t have to try and guess at what they might be, because you focus on the theory and the math that solves these games, instead. You’re not concerned about whether the values at some location on the matrix are accurate or not — you just assume that they are.

My opinion of gamification in the workplace is… low.

There’s Already A Game

It isn’t that gamification can’t improve things. It can! It absolutely can! Gamification can improve things… in very specific, narrow applications.

The overall problem I find with gamification of the workplace is that it is an abstract game layered on top of another abstract game — a game that we call “employment”. Attempts at gamification are games we are forcing people to play, on top of a game that they are already playing! The math gets… weird.

It becomes much harder to predict outcomes. You’re dealing with “higher order functions”, and those start to get tangled up together. Once these higher order functions start to enter into the mix, determining values in payoff matrices becomes a hell of a lot harder.

And if you can’t easily determine how the game pays out to its players, well… You’re just rolling the dice with your time spent building and implementing the game. It might all be wasted effort in the end if it isn’t developed properly.

Abstractions can be useful. By training, personal interests, and prior employment, I am a programmer. Programmers deal primarily in various types of abstractions. They take a set of business rules, and turn them into sets and systems of logical operations — some of which don’t necessarily look much like those business rules at a passing glance.

The additional abstraction is usually meant to be an efficiency increase of some type — otherwise, you wouldn’t need programmers! You would just have the business rules, and operate by those instead!

To argue the need for gamification is to argue that the abstract game “employment” isn’t functioning, or that you don’t have the ability to change payoffs in the employment game. It’s to argue that you need to correct the employment game with another abstract layer. It’s declaring your intent to “fix the incentives” of employment — to fix the payoff matrix.

I’ve heard it argued as “increasing productivity”, but the truth is that if your employment system is functioning, you should be able to increase productivity based on that alone.

If your employment system is correct — i.e., if you are paying the correct wage and are able to find the right people for the jobs you need done — you will be in some “equilibrium”, hovering around your theoretical “marginal effectiveness” of your employment system.

The traditional theory is that higher wages and benefits equal higher output (up to a point), for a number of reasons. You attract better employees. Your employees are happier. Your employees will want to leave your organization less, which saves you on hiring costs.

People will hear about the better working conditions at your company and give you a better hiring pool. And wages and benefits are only one factor that goes into the equation of employment and productivity!

Organizational structures, information flow between groups within a company, the societal culture you exist within with regards to “work ethic” — you could look at so many different factors, your head would spin!

The Time And Simplicity Trap

And this is the part that gets tricky, you see. It becomes so difficult to try to figure out the existing “game” of employment and the incentives that go into it that we develop an intense desire to simplify it.

And not only is it difficult to figure out, it also takes a while for changes to have any measurable effect. You won’t see any effects from a changed pay scale until you’ve hired a bunch of new people and they’ve been around for a while. How do you know you’re making the right changes?

“Wouldn’t it be great if we could just create a simple set of incentives that we could implement and tweak right now?” we say to ourselves. “Well, I read about gamification a while back… Let’s give that a try!”

Make no mistake about it, this is a heavy topic. Entire libraries exist about this kind of stuff. Political campaigns spending hundreds of millions of dollars live and die on the opinions surrounding theories about employment and incentive structures. Philosophers have discussed incentives, meaning, value, and equity for thousands of years.

This article is really only a blog post, of course. More noise in a sea of noise surrounding these topics. I will focus in on one very particular part of it all — gamification in the workplace — and I’ll only be able to scratch the surface of that particular topic.

To go any deeper would require a lot of graph paper, a good bit of calculus and linear algebra, and a thesis defense. And at the end of it all, I would just have some academic theory to talk about, not a real-world use case.

So, About That Real-World Use Case…

Some years ago, I was working for a company that had software for a reasonably-sized user base. One of the things I was very enthusiastic about was creating help documentation for users.

I often ended up with quite a few tickets every day that went, “How do I do THING with the software?” Answering this type of question wasn’t my primary responsibility, but it was one of many, and it often took a lot of time to respond to those tickets when I ran into them.

I had to open up the software, load up some test data, re-read the question because it was written a bit vague and using colloquialisms I wasn’t familiar with, click through a bunch of pages or screens, type in a lot of words, write all of these steps down while making sure I didn’t miss anything in the process… You get the picture. I was supporting the software, but I wasn’t a power user, after all. I was a dev.

Because of these tickets, I started writing a wiki-style “help center” of documents. These documents had steps that people could take to resolve errors or issues that they ran into. They had easy-to-follow, step-by-step instructions on how to do certain activities that weren’t intuitive.

So, each time I got a ticket with a new question that could be resolved directly by the user, I would write up the help document, and send them the link. I would include common phrases or statements in the searchable text of the document so that when users wanted to find a document, it would usually be the first one in the list of results.

I spent a lot of time refining and editing these documents based on feedback from the users who I sent them to. The feedback was constructive and positive.

Finding Equilibrium

For a while, it created a bit of an extra workload, but after a month or so it started to pay off for me. Less of these tickets were entering the queue. The ones that did make it through were quickly answered.

I not only became a power user from exploring the software more, but I was being bathed in the words that our users used in their day-to-day workflows. I knew a lot more about the industry they were in at that point.

I was naturally incentivized to do this activity. It saved me a lot of time in the long run. Instead of writing the same answer over and over for users, and instead of them having to go through the whole support help desk process, they could just find the answer themselves.

They’d find the answer quickly and they’d be happier for it. They even got to see their questions impacting the generation of these help documents in real time, with updates pushed out to them by the end of the day (or sooner). They felt like they were a part of improving the user experience of the software due to their questions.

Our game’s payoff matrix had sent us to the place where we were all benefiting each other. We were “in equilibrium and maximizing our utility”, to use basic economic terms.

I had a very high rating from users which to this day I am still very proud of (from a little help desk survey app system). It meant I was on to something with the way I approached the support work on the user’s end.

I felt accomplished knowing that users were being helped by my actions, and were happy with my performance. They felt like they were being supported in their work, and they felt like their questions were helping both themselves and their colleagues.

Win-win situations are the ultimate moves in game theory. It’s where you always end up, assuming that one exists, and assuming that there is a path available to get there together.

Anyway, back to gamification. That’s what this post is about.

Shall We Play A Game?

At some point, someone introduced a gamification strategy to the organization. There were a number of issues with the approach taken. I don’t fault anyone for this. “Making a game” is as abstract and herculean a task as any that a human could engage in.

The simplest view when it comes to gamification is something like… “Add points to things, people will compete, productivity will increase.” That seems easy, doesn’t it? Add points and profit from the game. Isn’t that a win-win?

The problem in this particular case was two-fold:

First, the points didn’t count towards anything tangible — you just had a score total displayed every month or so. It wasn’t really a big deal. No one was getting performance reviews because they didn’t hit some target number (thankfully).

It was just a point system layered on top of the things that you completed in your daily workflow. It didn’t mean anything at all, in the long run. There were little badges. It was a cute distraction.

And yet, it was a distraction…

The problem with assigning points to people is that it implies an awful lot of things. It implies value. It implies worth. It implies productivity. It implies competition and winners and losers. People wouldn’t assign points to things if those points didn’t mean anything, would they?

It’s one of the reasons so many organizations try to inhibit employees discussing their pay rates and salaries with each other — if person A is doing the same job as person B, and they’re both getting comparable results, but they’re being paid differently… what does that mean?

Salaries are “points” in the abstraction called the “employment game”. Sure, they’re points that have spending power in the real world, and that gives them real world meaning and consequences… but they’re still points.

They still have OTHER meaning based on their assignment. In some cases it means preferential treatment. In other cases it means seniority. In others, it means one of the parties was simply a better negotiator.

Points ALWAYS have other meaning when they’re shown to people. Goodhart’s law applies to every metric — point systems included.

Estimating Efforts: Pareto Strikes Back

Back to our point system: one issue was the value placed on making and updating documentation. In general — and in an awful lot of organizations — it’s hard to get people to work on creating and updating proper documentation.

It takes a lot of time to do, and the documentation is out of date the moment you change the system it describes. You’re building another system that you have to maintain in parallel with the primary system that it is meant to describe.

What could be a better way to create an incentive to get documentation done than to gamify the process a bit, right? Add points, people will compete, productivity will increase. And since documentation isn’t done often, let’s make them worth a ton! That will really incentivize people to get them done!

Well… I was writing a LOT of documentation compared to everyone else. The scoring worked out in such a way that I had an order of magnitude more than anyone else when it came to points, every single month. I was already engaged in a user documentation process that rewarded me appropriately, so the points didn’t matter.

It became a running gag that no one had to beat my score to win, they just had to beat a tenth of my score. The scoring system neglected to take my (outlier) time spent writing user documentation into account.

And this is a funny side effect of most systems of inputs and outputs, something known as the Pareto Principle, or the 80/20 rule. The Pareto Principle states that roughly 80% of effects come from 20% of causes in a system. Now, this is not perfectly true in all cases, of course — there is no exact ratio of specific inputs and outputs that always works out like this in every system.

It’s meant to illustrate that there are often causes that vastly overpower others, and are responsible for the large majority of results when measuring outputs.

In this case, in one very particular place that most people didn’t interact with, an awful lot of documentation was being created. This one very particular place happened to be my user help documentation portal. I was creating lots of documentation as a natural part of my daily activities.

This was completely unrelated to any point system or pressure from outside of my everyday workload. It completely overwhelmed the game’s point system.

So, lesson one about gamification: if you’re going to make a game out of something, make sure that the points are being tallied in a way that makes sense.

It sounds like common sense, but it’s not. Some people are doing certain activities far more often than anyone else in the organization, and applying points to these activities is probably meaningless. Instead of giving points to those activities in general, you should get a bit more specific about their calculation.

Perhaps they could have only totaled the points towards architecture or other high-level documentation — or only documents tagged with certain category labels — instead of including all individual and unplanned efforts like mine.

That could have brought the point system back to some realistic calculation — my crazy document generation, my outlier, would have been disregarded. Would that have been fair? Well… I think in the spirit of the game, yes, it would have been. Of course, had the point system been more specifically applied, you could probably disregard my outlier, which leads me to…

The second problem this gamification attempt had was one of breadth.

It’s Not You, It’s Models

There are game designers that work in AAA game companies with budgets into the hundreds of millions of dollars per title who can only somewhat effectively balance a game properly.

The game still requires months or years of real-world use in order to see how the players are actually incentivized and whether there are errors in assigning points. This isn’t a failure on their part, either — the human brain can only take into account so much information. The brain can only ever make a model of reality. Reality can always break the model.

The second problem with this example boils down to the total variety of actions that produced the point totals. There was only ever ONE point total tallied up.

A software developer working on one very difficult feature implementation over the course of multiple sprints was having their points totaled up against a business analyst writing multiple user stories each week. A tier I tech support person was having their points totaled up against a product development team manager.

How do you assign point values that are supposed to be compared to each other, when the actions that create those values are so drastically different in nature?

How many user-facing support documents equal one large data migration? How many low-level document edits equal a user story generated from examining support tickets? How many QA tests equal a custom report developed for the CEO’s business meeting with a new client?

This to me was the biggest issue with the gamification effort. How is anyone supposed to make a coherent point system out of these vastly different activities?

The Points Don’t Matter

One method that could have been attempted would have been to normalize the points given based on some metric — probably man-hours spent to complete each task. But that is a LOT of work you would have to do. That’s a LOT of data you’d have to capture and parse.

Take every single ticket in Jira and extract the actual man-hours needed to complete them? And all while assuming that the man hours spent were accurate when either estimated or counted, when the ticket was marked complete?

What about the activities that would never even enter a project management tool? I never created tickets for the documentation I created — I just did it, because I was incentivized to do it. Many other activities are exactly like that, completely missing from tracking systems and project management tools and Kanban boards.

And let’s say you somehow DO magically normalize all of the points to actual hours spent, or some similar metric… Now, all you really have are points that stand for hours! Why even make points in the first place, when you could simply look at the hours everyone spent doing things!?

The breadth of the attempt at assigning points to every different activity was the largest issue in the gamification effort. It’s like that show Whose Line Is It Anyway? — the points don’t matter. In this case, the points didn’t matter because they were describing a huge variety of actions that have no inherent comparability between them.

The True Price Of The Game

I don’t mean for this article to be one big complaint about gamification, but I do want it to describe common issues that a naïve implementation will have. And, unfortunately, in most organizations, you’ll end up with a naïve implementation.

Pretty much every first iteration of a game system is going to be naïve in some way. This is because making good games is actually much more expensive than most people realize. Even experienced game designers get this wrong. Constantly.

Unless you have an accurate and fairly granular measure of all of the activity in your organization that you want to gamify, there isn’t going to be a quantifiable way of setting point values. Full stop. You’re going to make a lot of guesses and you’re going to have to iterate.

Gamification can only work if you are able to devote one or more people to a complete full time effort at developing the system. Gamification won’t give you the results you think it will if you try to take a mid-level business analyst and have them do it in their spare time, along with their other responsibilities.

I don’t want to only talk down on gamification. I can see a use for it in very limited and specific applications. A sales team composed of people with very similar levels of experience and ability are all on equal footing in their daily requirements and outputs.

This is an application that a little gamification can help with, assuming the employment game has been played correctly and those incentives are all properly managed. It could encourage some competition and likely increase output due to the extra bit of incentive the game could provide.

The application is small enough to be able to know who the actors are, their daily workflows, and the pool of activity that they engage in. Maybe the gamification can be built around cold call totals? Everyone could likely agree upon how many cold calls lead to how many sales, roughly, so assigning points to cold calls actually has meaning to them.

But I can’t help but think that this is all a moot point, anyway, right? Results are already quantifiable in that team, aren’t they? If Susan makes 100 cold calls and gets 5 sales, and John makes 200 cold calls and gets 5 sales, do you need to gamify cold calls?

The thing you are ultimately trying to make are sales, right? Aren’t sales the points that you are already measuring? Isn’t there already a game being played, that game that I mentioned at the start — employment?

Susan is twice as effective as John when you look at cold call totals… but maybe her calls take twice as long to complete. Per hour, maybe they’re equals, and each salesperson has optimized to the types of work they do best.

John makes twice as many calls and bails out earlier on the ones he feels aren’t going anywhere. Susan sticks with them anyway and reaps the reward of that extra effort. Or maybe they spend equal time, and Susan is just twice as effective at cold calling. Or maybe Susan actually takes 4 times as long with these calls, and is only half as effective when you normalize sales based on cold call time.

Look… the details between those two salespersons don’t matter with regards to gamifying their work. The entire point is that the values that they need to pay attention to already exist. Those values are how many sales they make in any given time period. They are professionals getting paid to make sales. They know what their numbers mean and they know how to compare those values. They know if one of them is slacking. The social pressure to perform is already there.

Will gamifying their work squeeze out another 10% efficiency? 5%? 1%? And if it does increase efficiency, is the time and cost spent gamifying worth it? And if the time and cost ends up being worth it, will they enjoy it? And if they don’t enjoy it, will they find another company that doesn’t try to manipulate them into performing better with arbitrary point systems?

You know what I bet would get an extra 10% efficiency out of them, assuming they’re not already at max capacity? I bet if you offer them another 5% on their commission they’ll perform better. Those are points they can calculate easily. Those are points that directly map to their actions and results. Those are points that offer real incentives to achieve them.

One area I could see gamification helping the most is in training people to perform activities they aren’t comfortable with. This makes a lot of sense to me.

Perhaps you’ve introduced a new technology or methodology in a group’s workflow — maybe this group of salespersons only ever did lead generation over the phone, but now you have a new additional method that only goes through email.

There are probably members of the team that aren’t as comfortable with that method as with calling — and it shows, because the new email lead generation system is going unused. Applying some type of game to the use of that new system can give just the right amount of push to get people to use it.

The more they use it, the more comfortable they become, and the more comfortable they are, the more they use it. You’re using the gamification to encourage a bit of a positive feedback loop, to help kickstart the adoption of your new tool.

That application makes a lot of sense, doesn’t it? That’s not a game that’s a stand in for another metric — that’s a game with a purpose.

Focus On The Real Game

There’s a game already being played, and it’s called “employment”. It’s an abstraction built around profit motives and the need to pay for things like food and shelter in the modern economy. It’s a well-known game that has been played for thousands of years, so everyone understands the strategies involved.

The points can be used to purchase whatever reward you want, too! You don’t need to create a new company intranet portal with user authorization.

Functionality doesn’t need built to use those points to buy an extra day of remote work, or 2 hours of PTO, or tickets to the local cinema, or a gym membership, or a Slack emote. You don’t need to invest a developer’s time, and a business analyst’s time, and HR’s time to create it. It’s already there.

Why make another game? Focus on optimizing the one that everyone is already playing.

If you enjoyed this article, please consider stopping by my website and reading more - or just saying hi!