Leading Change - An Excerpt from Beyond Critical
May 24, 2012 Page 1 of 3
[How do you really motivate your development team to change its methods? In this excerpt from his book Beyond Critical: Improving Leadership in Game Development, producer Keith Fuller blends personal experience and literature to explain how you can steer your team.]
Okay, so you'll need to do something differently at some point. How? Being a leader doesn't automatically mean people will happily accept any given change you attempt to institute. I learned that the hard way the day -- and it only lasted one day -- I tried to force an entire team to only play our game using a controller instead of mouse and keyboard.
If the primary SKU is the 360, we should make sure programmers and artists are developing the game with the appropriate input device, right? Well... yes. But as I found out, enforcing Draconian measures may be fun, but more influential leaders than you and I have been escorted to the guillotine for such practices.
Clearly there are wrong ways to induce change. Let's get into some of the right ways.
I've mentioned that getting people to do something different or think in a new way is not only an uphill slog in and of itself but also tends to induce negative results before you see anything positive come of it. Nonetheless, as a leader you won't always be able to just sit back and let things stay the way they've always been.
In fact, numerous times I've stated my preference for continuous improvement, something that requires ongoing changes. It follows that a key aspect of leadership -- and one of the most difficult -- is the ability to incite meaningful, lasting change. For that very reason I tackled a book by Chip and Dan Heath, Switch: How to Change Things When Change is Hard.
In this excellent book, the authors provide data from scientific studies as well as numerous examples from academic, health, and corporate sectors, all of which address the difficulties of change and how to overcome them. The Heaths categorize their material within the context of a metaphor borrowed from University of Virginia psychologist Jonathan Haidt.
Our brains, Haidt says, can be thought of as comprising a Rider and an Elephant. The Rider -- our rational side -- sits atop an Elephant, representing our emotions. Able to plan long-term and think beyond the moment, our Rider seems to be in charge but is easily overmatched by the six-ton Elephant's laziness, skittishness, and desire for instant gratification. The rational Rider and the emotional Elephant have strengths and weaknesses and both must be considered in order to make a change.
To this analogy our authors add a third element -- the Path -- which is summed up by their statement, "What looks like a person problem is often a situation problem." You can provide reasons to the Rider and you can give the Elephant some alluring motivation, but you can also make change more likely by altering the environment, i.e. shaping the Path. These three components of the change metaphor all have a bearing on leadership in game development. And here's the first.
Anyone who has tried to stick to a New Year's Resolution or a diet or an exercise routine knows that rational decision-making isn't enough to institute lasting change. The Rider has a tough job managing that Elephant. It's hard enough for you to keep your own rational side in charge of your emotions, but as a leader trying to induce change in your organization it falls to you to keep everyone else's Elephants in check, too. Clearly, your Rider needs all the help they can get.
Switch describes a few methods for directing the Rider, but the one I want to touch on here is referred to as searching for "bright spots" -- successful efforts worth emulating. The basic idea is simple enough and is something for which your rational mind is particularly well-suited: in any given set of ongoing experiences that you want to change there is a subset in which things are going well -- or better than average, at any rate. Look for those, figure out why they're above the curve, and clone the behavior elsewhere. I'll give you an example of how this worked while I was producer on a World War II-themed shooter.
Page 1 of 3