Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
106 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

Pull Together: Getting Team Buy-in


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.





Page 2


Contents
  Page 1
  Page 2

  Printable version
  Discuss this article