Pull Together: Getting Team Buy-in
by Rafael Chandler

It's a hell of a start
It could be made into a monster
If we all pull together as a team
-- Pink Floyd, "Have A Cigar"

As development studios ramp up to meet the demands of next-generation consoles, dev teams get larger, and new communication norms are required. Between new hires brought in to meet manpower demands and veteran employees who roll from production cycle to production cycle, it becomes ever more important to establish the vision of the game early on, and to get the team's buy-in.

Not every member of your team will have the time (or inclination) to read design documents or play the latest build of the game. However, if the team is not on board with the game's core concept, it can lead to confusion and misunderstandings.

Motivating teams, educating new hires, and keeping the old-guard employees up-to-date with changes in the game's core concept can all be daunting challenges. But they don't have to be. There are specific things that can be done to get the game vision across to the team, and these techniques can improve efficiency, camaraderie, and general working conditions on a project.

These methods can be executed by a producer, designer, or anyone else who is familiar with the game concept. Some of these can require time, money, or assistance from artists, but only in small amounts.

If you employ some of these techniques, your team may snort and laugh, and some may tell you in private that the idea was somewhat corny. That's okay. You don't need to worry about that. You do need to worry about your team working in the dark, unsure of the direction that they're going in. You do need to worry about your team getting pessimistic. You do need to worry about your team fracturing on discipline lines -- engineers over here, artists over there -- not communicating with people outside their discipline.

While these techniques won't solve all of those problems, they can build camaraderie and a sense of accomplishment, and get the team excited about and enthusiastic for the game. If you're doing anything to keep morale up, you're off to a good start.

From the Top Down

There exists in this industry (and others) an erroneous assumption that true buy-in comes from the team's creation of their own vision. This is simply not the case. As Katzenberg and Smith point out, "it is the exceptional case -- for example, entrepreneurial situations -- when a team actually creates a purpose entirely on its own. Most teams shape their purposes in response to a demand or opportunity put in their path, usually by management."

The fact is, you can't get a dev team of dozens to collaborate on developing a coherent vision through consensus. Most of the time, the game's vision is handed down to the team in big-picture format, and the team is challenged to implement this vision.

Therefore, these methods aren't going to make your team feel like they're getting the vision crammed down their throats. They won't feel demotivated because they're being told what to do. On the contrary, these techniques will empower your team by furnishing the core concept of the game, without delineating specific tasks or robbing them of creative agency as developers. And they will feel as though there's a clear expectation, a goal to work towards as a unit. This will improve morale and the overall quality of your game.

Review

The review is written from the perspective of a game publication, as though the game has already shipped. The review is dated around the approximate release date, and focuses on the core elements of the game. It is intended to give the team something to work towards, so keep it realistic. If you're working on a phone game, tell it like it is. It's a good phone game, it's worth buying. It's fun, it's got good graphics. It's not going to outsell Halo 2.

By calling out a number of key features, and praising the stability and solid graphics of the game, you give the team something to anticipate. You also educate your team members about the game's key selling points, and clarify the feature list from the perspective of the consumer, which will bring new hires up to speed quickly. They should put the review down and think, okay, that's what we're doing.

The review can be typed up in Word and emailed or printed out, or you can get elaborate and set up a fake online review and host it on your team intraweb. It can be mocked up to look like a print magazine review and tacked to a bulletin board, or it can be presented to the team in a slideshow presentation.

Obviously, the team shouldn't be told that the review is genuine. Whether it's presented as a new kind of design document, or as a humorous closer to a team meeting ("Well, we got a transmission from our future selves two years from now, and hot damn, it looks like this game's going to be a hit."), it's important that the team understand that the review is intended as a motivational tool.

This method is particularly valuable if the game hasn't even been announced yet. When the team is working on a project that they can't even talk about, it's gratifying to have any kind of attention paid to it, even if they're well aware that the review isn't real.

Box Art

The final product is the finish line that all developers are working towards. When the game is done, and it's possible to hold the box in one's hand, there's a feeling of accomplishment. Getting a taste of that glory early on can motivate your team, as well as crystallize the core selling points of the game. By using an art program like Quark or Photoshop, and some relatively inexpensive plastic cases, you can convey the basic ideas of the game that your team is working on.

Depending on where you are the in project, you may have access art assets such concept art, or in-game character models that can be rendered out. Build your cover image with one of these images, or a montage, and use your game's title and logo (or invent one -- remember, this is a mock-up and a team-building exercise, so don't worry about whether the logo is an exact match with the finished game). On the back of the box, place screenshots taken from your latest build (or mock them up if it's too early in the process for a screenshot), and write bullet points based on your game's key features. After printing the artwork, slip it into a DVD case or CD jewel case.

For your more experienced employees, this game will be another box on the shelf, and for the new hires, this can be a profoundly effective motivator. It will also serve to get the team marching in the same direction, by establishing the core selling points.

Don't just walk from desk to desk to hand these out. At one of your team meetings, bring in some cardboard boxes, open them, and hand out the cases. Let people crane their necks, eager to see what's going on. When everyone's got a copy, do a quick show-and-tell. Call on some of your artists and engineers and designers to explain some of the bullet points on the back of the box. Turn the event into an opportunity for dialogue and camaraderie. Then crack the whip and get those goldbrickers back to work. Just kidding.

Posters

Poster and flyers, printed up and posted around the building, remind the team of what they're working towards. They serve as a reminder of the main characters or iconography of the game, and can introduce these concepts to new employees. These also are a concrete depiction of game elements, which can be very useful if the team hasn't got any demonstrable gameplay yet. These also foster a sense of pride in your team.

You can use concept art, rendered images, or even new artwork commissioned from one of your 2D artists. The goal is to create a strong image that can be recognized and admired by the people on your team. Use movie posters as a reference point. In fact, you may want to put credits at the bottom of the poster, and use the names of your game's characters as the "actors". However, unless your team is very small, you'll probably want to avoid citing any actual developers on the credits. It won't create the buy-in that you're looking for; it will only make the other devs jealous and confused. Your best bet is to use the names of characters in game, and make up names for the other credits (Directed by, Written by, et cetera).

Digital version of these posters can be made into wallpaper, which, when emailed around to the team, will proliferate on their computer desktops as a badge of honor. People tend to work in this industry because they care about games. Give them a chance to show off the game that they're working on, and they'll do it, even if only internally (as is the case when the team's working on an unannounced title).

Again, these is best handed out at a team meeting. Give the team a chance to socialize and hang out. If the budget permits, create more than one poster -- hand them out every couple of months. Get the team involved by contributing logos or artwork.

Video

Gameplay footage, however raw it might be, gives your team an idea of what to expect. If it's too early in the process to take footage of gameplay, you can use storyboards. Storyboards are often created as a part of the gameplay design or cinematic design. However, these can also serve a function as a tool to illustrate the game's concept for the rest of the team. You can create an animatic sequence through the use of video creation software. Windows Movie Maker ships free on some versions of Win XP. If you don't have that program, then hassle your cheapskate producer for the money. If you're a producer, um, sorry.

After exporting your still images as a slideshow, set it to music. Or, if you have other audio assets available, you can add these to your video. It's not important to create an elaborate movie with scripted dialogue and appropriate sound effects. The focus should be on giving the team a preview of what the game feel will be. This can clarify a new direction for an existing franchise, or convey the idea of a new kind of game to your team.

You may want to debut the video at a team meeting, or schedule a separate meeting for the screening. If your movie is elaborate enough, you may want to add some fun to the proceedings by making popcorn. Either way, allow time after the screening for discussion. If people have things to say, positive or negative, you've got communication.

Group Playtest

When there is a multiplayer build stable enough to play, get a group together and play it. Make it known that the purpose of the playtest is not to find bugs or to critique artistic decisions -- there will be time enough for that later. The point is to play the game, and to get a feel for what the multiplayer aspect is all about.

Establish some ground rules for the session before play begins. The purpose is not to find fault with anything. The purpose is not to test the shell, or the menu. Don't jump in, then exit out and restart it to see if anything goes wrong. Just start up a server, get in the game, and frag people (or start killing rabbits, or stealing cars, or whatever).

If your game features team-based multiplayer, assign teams arbitrarily beforehand. You don't want artists on one team and designers on another. You want to mix up your developers, so partner people who don't know each other well. In addition to getting people excited about the game, it will help form bonds between them. They'll start communicating, and this will streamline matters immeasurably.

If your game doesn't feature multiplayer, there's no reason you can't set up four stations and get everyone together for a solid hour of gameplay. Let people take turns, get everyone around to watch and heckle.

Later, after the session, have your dev team send their feedback. You may want to set up an intraweb forum where they can post their comments, or you may want them to send email to a specific person. Just ensure that the playtest session itself is free of negativity. You want the session to be a venue for fun and team-bonding. Make sure that they reserve all commentary for the post-game feedback.

Conclusion

As a game lurches out of the preproduction phase and slouches towards final submission, its hour come round at last, you hope that your team has a strong vision of the game that they're all working on.

Ultimately, the strategies outlined above are all just extensions of a single idea: present the team with the game concept (but not in the form of interminable design documents) and get them excited about it. Get them talking to one another. Break down the barriers to communication and get them working as a team.

Make it fun.

Reference

Katzenbach, Jon R., and Smith, Douglas K. The Wisdom of Teams. New York, HarperCollins Publishers, 1999.

About the Author

About the author: Rafael Chandler is a game writer and designer at Red Storm Entertainment. He got his start in the industry at Electronic Arts in 2000. He has worked on over 20 games in a variety of roles, from QA Tester to Designer to Writer. His credits include games like Majestic, Motor City Online, Ghost Recon 2, and Rainbow Six: Lockdown. For more information, visit www.draconianproductions.com.

Discuss this article in the forums

Date this article was posted to GameDev.net: 6/27/2005
(Note that this date does not necessarily correspond to the date the article was written)