Blame the game, not the player

It was probably the “Principles” book by Ray Dalio where I first saw this thought, and it really clicked for me.

Multiple interpretations of this statement are possible, and the most popular one is that instead of blaming individuals for their mistakes, you have to focus on solving the underlying problem. While solving issues is great, I would like to present a different perspective which is not only about solving issues.

So what’s the idea? Changing people is difficult, but changing processes is relatively easy. Instead of asking people to start doing X, you can set up a system so that doing X becomes natural. Adjusting the system is definitely more effort from you than just asking your employees to put their effort in X, but it’s never about you and others – it’s about the team/department/company. And in this case, the effort of one to make some positive thing effortless for even a small team is a massive win.

The interesting representation of this idea is the concept of desk jumping in the gaming industry. Desk jumping is when the player does something that the player character would never do because they have different motivations. While this is always fun for the player currently, it can have serious consequences eventually, such as breaking the narrative. So how the problem of desk jumping can be solved?

It is possible to prohibit desk jumping by only allowing players to do what you want them to do (and maybe even punishing them for wrong actions). But this approach leads to a decline in engagement and loss of faith of players in game mechanics.

Another option is to ignore the desk jumping. This way, players will still have the freedom to do what they want to do, but with no effect and because of this, they will quickly get bored with doing unwanted actions. Definitely better than limiting player’s freedom, but ignoring is not a solution to the issue.

The best solution to the desk jumping problem is to design the game so that the player and character have the same motivations. Obviously, this is not an easy task for the developers, but in this case both they and the players get what they want. The important thing here is that 100% alignment is not required, and it will be enough that the player and his character want to perform the same action.

So what can we learn from desk jumping? First, it’s never about changing people, Second, people in a team/company may have different motivations, but the system should allow them to satisfy it by working together towards a common cause.

And here are some examples of how you can apply this idea:

• Instead of requiring work with specific technology, you can loosely encourage it by providing great developer experience for those who work with it;

• Instead of requiring participation in internal projects and cross-reviews, you can encourage it by allowing people to dedicate part of their project time to it;

• You can define the technical debt ratio and things like “Fix it Friday” so employees can dedicate time to resolving technical debt.