Beyond the pitch: getting your team engaged and excited about a game development project

Beyond the pitch: getting your team engaged and excited about a game development project

The Game Outcomes Project is an independent industry/academic partnership.  It is driven entirely by intellectual curiosity.  Our mission is to survey a large number of game developers and statistically analyze the connections between game development team culture and project outcomes.  We ran our initial study in late 2014 and published the results in Gamasutra and on Paul Tozour’s blog in early 2015.

The articles in 2015 took a very scientific approach to analyzing survey data and attempted to draw correlations between cultural and non-cultural factors that affect team performance.  Our recent research is based on interviews (qualitative data) and, while we lose the ability to run traditional statistics, the data has depth and is loaded with lots of real-world examples from experienced leaders.  We will attempt within these articles to present practical ideas that you can use when leading game development teams.

A primary objective of the Game Outcomes Project is to engage the broader industry community in a dialog about how to lead successful teams and projects.  Over the past several months we have spoken one-on-one with 9 successful leaders in the Games Industry about the validity of our previous findings and asked for input on areas they feel we should explore further. 

Every leader we spoke with agreed that establishing the vision early and then protecting and nurturing the level of enthusiasm and engagement on the team are critical to success.  We heard many stories and examples of how some leaders have done this successfully across a broad variety of game projects and constraints.  Three primary themes emerged in the data around establishing and maintaining the vision, along with several secondary themes. Each will be explored below.

Establishing the vision means finding a way to communicate to members of the team what the game is going to be.  There’s a lot of literature and resources about writing a vision statement for a business but not a lot of guidance available for writing a vision statement for a Game project.  We offer these suggestions about formulating a vision statement to share with the development team.

A vision statement is for internal use.  It is written to inspire your team. It is not the same as a marketing statement that will be used to sell the game.  Use language that will be well understood by the members of the team. A game vision statement should almost always describe the genre and express the reason people will want to play the game.  You want to infuse passion and emotion into the vision statement.  You may use words like: scary, exciting, addictive, social, surprising, immersive, light-hearted, fast-paced, strategic, entertaining, educational…

A vision statement creates a graphic mental picture by including descriptive words like: dark, whimsical, futuristic, floating in air, rocketing through space, medieval, photo realistic, angular, irregular, bright and colorful, cold and dark alien world…  A vision statement may also state what the game is not by way of comparison or contrasting it to another well-known game within the same genre or within the franchise, if you are making a sequel.

THE VISION STATEMENT SHOULD BE CLEAR AND CONCISE.

A prominent theme with the leaders we spoke with was that the vision statement needs to be concise and easily understood.  Seppo Helava, Co-Founder and Creative Director at Wonderspark, talked about using a one-line expression of the creative vision, an “X” statement, that the team can easily grasp and remember.  He compared this to giving the team a hundred-page design document and asking them to read it and then use it to guide their decisions.  They might read it once but would never look at it again and would soon forget what is says.  This isn’t to say that design documents are useless. They may serve a purpose but they do not replace the need for a vision statement.  Seppo went on to say that by posting the “X” statement visibly around the work area and using it regularly, it becomes ingrained and easy for the team to consider an idea and quickly and collectively agree if it is compatible with the vision.

We spoke with Kate Edwards, the Executive Director of the IGDA. Kate highlighted “Rise of Nations” as a good example of affectively sharing the vision.  “In the day-one meeting, Brian Reynolds, fresh out of Maxis, shared a vision for what he thought the game was going be.  This meeting was attended by all departments and disciplines.  He did a great job of articulating the vision and you could tell that everyone was onboard from the first day.  Specifically, he did a great job of articulating what distinguished this game from Age of Empires and Civilization, while acknowledging that it would be similar, in the same genre. “

DEFINE CONSTRAINTS EARLY

The concept of constraints came up in multiple conversations about establishing the vision for a game.  We spoke with Clinton “Clint” Keith, who described himself as an “organizational therapist” and is the author of “Agile Game Development with Scrum”. Clint commented that the team must understand both the vision and the constraints from the very beginning of a project.  If members of the team understand the constraints, they can much more effectively contribute to the creative process.  Examples of constraints include: ship date, genre, platform, game engine, etc.  Providing the team boundaries early helps keep them from wasting time exploring ideas that don’t align with the vision or fit within the constraints.

A similar theme was also echoed by Keith Fuller. Keith provides leadership training and is the author of “Beyond Critical: Improving Leadership in Game Development”.  He talked about constraints as external motivators and stressed how important it is to communicate the constraints and be transparent about why the constraints are in place.

When we asked Andre Thomas, CEO of Triseum, an educational games company in Texas, about communicating constraints he had this to say.

“Honesty! Total and utter honesty and transparency about the constraints. Here’s the constraint (here’s the engine we’re using) and here is why.”  He went on for several minutes about the importance of explaining why the constraints exist.  If a constraint is a specific ship date, don’t just tell them the date, tell them why it is that specific date and not some other date.

DISCUSSIONS ABOUT VISION AND CONSTRAINT SHOULD BE CONVERSATIONS

Of course, making games is a very creative endeavor and all agreed that someone, an individual, needs to ultimately be responsible for the big decisions about the creative direction for the game.  Yet we also heard a common theme that establishing the vision requires participation.  Dave Swanson, Director of Engineering for EA Sports, talked about the importance of one-on-one dialog with members of the team.  It is good to have a big meeting where the Lead Designer pitches the game concept but Dave recommended also taking the time to talk with each member of the team individually to make sure they understood the vision, and, most importantly, understand their role in the project.

We heard a similar theme from Andre Thomas.  Andre stressed the importance of including the members of the team in the design discussions from the beginning.  These should be conversations, not presentations.  Andre also described how these conversations need to continue during development as things change and decisions need to be made.  Andre described his best project as one that had many iterations, along with various approaches and dev waste along the way. You can only do this and maintain the team’s buy in if you are talking and including the team in the decision processes.

As we talked about communications we also talked a bit about organizational structure and how important it is to try to keep the organization as flat as possible.  Clint Keith commented that communication is more challenging on big teams.  He referred to Dunbar’s number which suggests a cognitive limit to the number of people we can maintain a stable social relationship with.  Scrum best practices prescribes smaller teams (9 or less).  Clint further explained by talking about how larger teams and organizations will tend to have hierarchical structures that cause communication channels to be more complex. Smaller, flatter organizations facilitate communications.

Clint shared this with me from the Valve Handbook:

Welcome to Flatland

Hierarchy is great for maintaining predictability and repeatability. It simplifies planning and makes it easier to control a large group of people from the top down, which is why military organizations rely on it so heavily. But when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value. We want innovators, and that means maintaining an environment where they’ll flourish. That’s why Valve is flat. It’s our shorthand way of saying that we don’t have any management, and nobody “reports to” anybody else. We do have a founder/president, but even he isn’t your manager. This company is yours to steer—toward opportunities and away from risks.

In summary, here are the three main points:

Whether you are leading a small team, a large team, a team that has worked together for years, or a brand new startup with lots of uncertainty, you need to make sure everyone on the team is on the same page.  This is a well-documented principle in the science of leadership and managing teams, as we discussed in our articles in 2015, and the stories shared by those who we talked to recently reinforce the importance of sharing the vision and then maintaining an infectious enthusiasm for that vision throughout the duration of the project.

There is no magic formula or plan you can follow every time that will guarantee success on your game development projects. You have to be a learn to be a strong leader and visionary. Keith Fuller described the importance of leadership like this:

“I’m very much of the opinion that, if you have crummy leadership for your project, for your company, all the best processes and tools are still going to put you in a serious problem. If you have great leaders and don’t necessarily have all the other answers you’re in better shape than the inverse.”

We want to thank all of those who have participated in the discussions that were shared in this article.  Their willingness to share their experiences and lessons learned is vital to continuing the broader discussions about important topics that help us all grow in our ability to be effective leaders and increase our odds of success in running game development projects.

Leaders who contributors to this article included:  Seppo Helava, Joe Hoff, Clinton Keith, Keith Fuller, Dave Swanson, Andre Thomas and Kate Edwards.

Our next Game Outcomes Project article will focus on crunch and take a deeper look at why crunch may not be as helpful as some leaders or studios want to believe.  We will discuss some of the studies done regarding effects of working long hours on productivity and offer some advice on how to measure for yourself if you really are getting more done and better results when teams work more hours per week.  We will hear more stories from the leaders listed above and we will hear from some additional leaders who spoke passionately with us about the culture of crunch within the games industry.