Creative Motivation and Agility

In 2009, the non-fiction book “Drive” written by Dan Pink was published. The book summarized research demonstrating that creative workers are not motivated so much by financial incentives or other such explicit motivations, but by intrinsic factors.

The three primary intrinsic factors identified are:

• Autonomy - The urge to direct our own lives 
• Mastery - The desire to get better at something that matters 
• Purpose - The yearning to do what we do in service of something larger than ourselves 

We want motivated teams. We want to be on motivated teams. We want to be motivated ourselves, but a studio’s culture and process can often prohibit it.

This is where the agile values and Scrum practices come into play: 

• Autonomy - The purpose of self-organization is to give the people closest to the work autonomy in taking greater ownership, as the become ready for it, over more and more of their work. At first it might be how they plan and track their Sprint. Later, it’s how the team membership is managed and the practices they use to create an increment of the game. 
• Mastery - By giving the team the freedom decide “how” they implement a Sprint, they are given permission to explore better ways of working. For example, when our level artists were given the freedom to explore new ways of creating levels, they eventually found methods that reduced level creation time in half. Note: the challenge to doing this wasn’t with them, but with the lead artists who had a problem letting their people do things “their own way”. For some reason they fought to have the less efficient level creation practices restored. 
• Purpose - By forming teams that are aligned around a feature area of the game, rather than a discipline silo, developers are far better connected to the purpose of their work. It’s easier to understand if what you are doing helps improve the game when your Sprint goal is to demonstrate an enhanced feature or mechanic than to simply accomplish all the assigned tasks in a tracking tool that contributes to something you’ll see in the game a month or so later. 

This all sounds great, but it’s very hard to implement in a culture that doesn’t place a lot of value on intrinsically motivated developers. The signs of this are:

• Developers are largely seen as “fungible”. E.g all animators are equally weighted on a spreadsheet or tracking tool, where skill and mastery could for little. 
• The idea that more developers can be added to a team to make the team more effective. 
• Management exists to define how developers do their work and to find and address the problems that arise. 
• The purpose of what is being done exists in the design document and if developers want to know the purpose of what they are doing, they simply need to “read the doc”.
• Etc. Etc. 

Another hard part is that motivation can’t be forced on developers. They have to find it within. The role of leadership is to help create the conditions for intrinsic motivation to flourish. I’ve worked with some developers that have been so beat up and burnt out by bad leadership that they refuse to extend themselves again. They don’t want to be disappointed again (what to do in these cases is the subject of another article).

Game development leaders should always be asking themselves: “how can I help improve upon these intrinsic motivators?” A core part of this practice is improving the feedback loops so that increases in autonomy, mastery and purpose are quickly reinforced and that mistakes are not punished but initiate a conversation to highlight what valuable thing we learned from the experience.

The ultimate joy, as a leader, comes from this cycle being taken over by the team. I’ll leave you with one warning: When your teams start outperforming your expectations, you might get promoted away from them; good leaders get recognized and are given greater roles.