Leading Change - An Excerpt from Beyond Critical

[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.

Creating a triple-A game is difficult enough but it gets a lot harder when it takes place in a predominantly open world setting, which was the case for the project in question. Worse yet, however, was the fact that our underlying tools and rendering technology were designed with a room-and-corridor game in mind. Our level design environment was geared toward photo-realistic lighting created by meticulously hand-placing a multitude of point lights in careful balance with various directional lights.

The upside of such a method is that you can make any particular area look amazing. The downside is that it is incredibly time-consuming to properly light, say, an entire German town.

Given the fact that our tools were mismatched to our task it was no surprise that our department of 13 level designers was moving at a snail's pace through their assigned work.

None of our levels were getting created in a timely fashion with respect to the overall project schedule. Management identified that the lighting stage of the level creation process was taking a particularly long time, so I set out to inspect and adapt our process.

My first step was to find out which of the 13 designers was capable of lighting a given area in the shortest amount of time. This led me to Mike, a senior designer and veteran of many iterations of the toolset in use. He seemed to be able to light his maps in a much shorter time and with better results than anyone else on the team.

I did my best to analyze his workflow and see to it that it was passed along to the rest of the designers. I'd love to be able to say that this approach produced such marked improvement that we were able to salvage our schedule and ship on time, but all we determined was that if everyone was as efficient as Mike we would be able to ship the game a year late instead of a decade late.

So we cut content instead.

But you see what the theory was, right? I looked for a bright spot and tried to clone the successful results elsewhere. That's directing the Rider. Determine some good directions -- preferably as concise as possible -- and relay those clearly to the rational minds of the people involved so they don't have to work so hard at controlling their Elephants.

For other examples of using "bright spots" to induce successful change I highly recommend Switch, specifically Chapter 2. If you'd like a particularly stirring example you can read about how Jerry Sternin reached 2.2 million Vietnamese and made a significant dent in that nation's malnutrition problem by looking for bright spots among the country's villages.

There are other Rider-directing methods available to you -- such as solutions-focused brief therapy -- that I think hold great promise for leaders in game development, but I'll leave those for another time.

That's our introduction to the Rider. Now we move our discussion to the emotional side of our brain, the perilous pachyderm.

You're a leader. There are times when you will be told to implement change and there are times when you'll want to do it of your own accord. Either way, you'll need to get people to alter their behavior and do something new or different. That means you'll be dealing with the Elephant.

In The Heart of Change, John Kotter and Dan Cohen talk about a study they ran in conjunction with Deloitte Consulting in which 400 people were interviewed from 130 companies across four continents. The subject was why change happens and part of their summary is as follows:

"...the core of the matter is always about changing the behavior of people, and behavior change happens in highly successful situations mostly by speaking to people's feelings.

"This is true even in organizations that are very focused on analysis and quantitative measurement, even among people who think of themselves as smart in an MBA sense. In highly successful change efforts, people find ways to help others see the problems or solutions in ways that influence emotions, not just thought."

It's entirely appropriate to envision the emotional part of your brain as an Elephant because this is the problem you're dealing with: it will move in whatever direction it likes with all of the ponderous inertia of a coasting barge. Trying to force it down a different path will take an enormous amount of effort on the part of the Rider. To translate this into managerial terms, all the PowerPoint decks and Excel spreadsheets in the world aren't going to have the same impact as a comparatively meager supply of facts coupled with emotional involvement. Here's a great example from Switch to drive this home.

Most of us know how attached developers get to their code. Microsoft apparently encountered this same issue when a test lab reported to some programmers that six out of 10 users couldn't figure out a new feature. The response from the engineers (which you can well imagine coming from your own team) was, "Where did you find six dumb people?" In the face of such reticence how could the test lab get the engineers to care about the user feedback?

One of the things Microsoft did was to invite the developers to visit a user testing session and observe from behind one-way glass. Watching someone struggling with the software immediately generated empathy with the user. The lab manager said, "The usual nonsense answers -- 'Well, they can just look in the manual if they don't know how to use it,' or 'My idea is brilliant, you just found six stupid people'... that kind of stuff just goes out the door." Thus the Elephant was motivated.

This approach works wonders in game dev, too. If you've never had the opportunity to observe a focus test I highly recommend you do so -- not just for the value it will add to your product but also for the professional growth you will undoubtedly experience.

It's so easy to get too close to the game when you're working on it. You know where the enemies spawn, you know how the bear AI works, you know which letters are worth the most and if you can make that jump to the lift. You lose sight of the first-time player's experience with the title without even realizing it.

When you sit on the other side of the one-way glass, though, and watch someone pick up your game for the first time, you get the same revelation as those Microsoft engineers. Why do we make it so hard to find the switch? How could we have made the timing on that attack so difficult? Nobody will ever buy the IAP because they can't even find the menu.

You'll come away with an appreciation for the importance of real player feedback. As Robin Walker of Valve has said (paraphrased by journalist and indie developer Tom Francis), you don't know anything about an idea until players have tried it. So watch them try it.

As an example, let me tell you about Stu. Stu was one of the many awesome level designers I worked with on X-Men Origins: Wolverine. He was renowned for making his puzzles a little too hard, but he always made them appear easy when he played his own maps. True to form, he once reported a particular traversal segment of the Sentinel Labs was totally reasonable and didn't require nerfing. A few others challenged his viewpoint.

I'm actually pretty awful at such games, so I was asked if I could beat this section. After my first attempt, I failed so badly that I deemed the level nearly impossible, and set out to determine how many times I would have to try this traversal before I could do so successfully. Given that I had other things to do on the project, it took me over a week, but eventually I managed to make it through the area -- after 47 failed attempts and several thrown controllers (Seriously. 47. I tracked them with hash marks on a sticky note atop my TV).

One other detail I should mention: Stu's desk was right next to mine. For a week straight, every time my controller landed on the floor in frustration he knew why. In short order he relented and the traversal was modified. And lest you get the wrong idea, I love Stu.

When you ponder how to make a change at your company, keep in mind it's not just about directing the Rider. You also have to motivate the Elephant. Figure out how to make an emotional impact. Appeal to someone's sense of adventure to get them to rapidly prototype a new feature. Inspire them with examples of the quality coming out of other studios and indie groups. Do something other than simply present facts and figures and you're likely to meet with much more success.