How To Build A Motivated Team (1996)

tim-cain interplay fallout team-management game-production leadership 1990s

Abstract

Problem: How do you build and maintain a motivated game development team when producers receive zero formal training?

Approach: Tim Cain reads aloud a presentation he wrote in late 1996 at Interplay, where Brian Fargo asked him to share his team management approach with other producers — impressed by the high morale of the Fallout (then "GURPS") team while other teams struggled.

Findings: Motivation comes from four pillars: start with yourself (pick a project you love, create a clear design spec), get the right people (let them volunteer, prefer well-rounded people and "catalysts"), set up the team properly (flat structure, physical proximity, cross-discipline input), and run the team well (weekly meetings, uninterrupted work time, meaningful deadlines, ownership through novel challenges).

Key insight: People who ask to join your project come pre-motivated — and people who see their own ideas come alive in the game will fight to make the whole thing great, because nobody wants to be associated with a terrible game.

Source: https://www.youtube.com/watch?v=shH7tTIUNWc

1. Background

In late 1996, Brian Fargo asked Tim Cain to address Interplay's other producers at their regular producer meeting. Fargo was impressed by how Cain was running the Fallout project (then called "GURPS") and specifically by the team's high morale — while many other producers were complaining of low morale and poor work ethic.

Cain didn't consider himself a particularly good producer. He notes "the bar was low for good production at Interplay" — not because producers weren't trying, but because there was absolutely no training. When Cain asked the executive producer for training, he was told "that's not how they did things — they just threw people in the pool to see who could swim."

The presentation resurfaced years later when an ex-Interplay coworker gave Cain a printed copy. Cain describes the document as "not an example of good production guidelines" but rather "a time capsule that shows what great production was considered to be at Interplay in the mid-90s."

2. Step 1: Start With Yourself

Before embarking on any project, Cain advises producers to make several personal decisions:

  • Know your genre. Understand it deeply. Play games across PC, Mac, arcade, and even pencil-and-paper. "You never know what may trigger the next great idea."
  • Pick a project you love. "Few things are more demoralizing to a team than to work on a project whose producer doesn't care about it." If assigned a project you don't like, complain loudly — don't assume you'll grow to like it. Even desirable projects become tedious at the end; if you don't like it at conception, you never will.
  • Don't take on too many projects. Ideally one per producer. If you must handle multiple titles, focus creative energy on just one. "You cannot devote yourself to more than one A-grade title at a time." Your team won't function well with your divided attention — you can only be part of one team.
  • Create a clear design specification. Whether a written document, storyboard, or prototype engine. It helps anticipate resource needs and shows others you're planning seriously, which attracts resources. If you can't make the spec yourself, get a competent designer to make one.

3. Step 2: Get The People

3.1. Let People Choose You

Teams work better at Interplay when members asked to join rather than being assigned. This factor is so important that it might be worth waiting months for the right person to finish their current project rather than taking whoever is available. That waiting time can be used to finish the design spec.

3.2. Hire Well-Rounded People

Don't just take the first person best suited for a specific job. Look for well-rounded people who can do more than the immediate task — they'll serve you better when unforeseen tasks arise later. Look for people who aren't afraid to try new things.

Example — Leonard Boyarsky and the clay heads: When Leonard Boyarsky joined the GURPS team as lead artist, he wanted to try using clay heads in the encounter window despite never having worked with clay before. The technique required inventing an entire process — sculpting, scanning into 3D models, adding facial features, animating the results. The outcome was "the coolest looking heads since Max Headroom first aired." All because Leonard wanted to try something new.

3.3. Find "Catalysts"

Referencing the book Peopleware by Lister and DeMarco, Cain describes "catalyst" employees — people who make teams gel. A catalyst isn't necessarily the best worker at their own job, but they make everyone else better by understanding other members' jobs and coordinating efforts.

Example — Jason Taylor: A catalyst on the GURPS project because he both programmed and used art utilities. He understood how 3D art translated into game art specifications and how animation code worked. He'd suggest changes to art or code that made animations smoother or used less memory. He organized art priorities so the most important work was done first and similar art was done together for visual consistency. "Jason would save us man-months of time by spending an afternoon thinking about the code and art together rather than in separate parts of the game."

3.4. Get the Right Team Size

Get enough people to meet project needs — and no more. Too few means overworked and frustrated people. Too many (unlikely at Interplay) means coordination nightmares and idle team members. If you can't get enough people approved, reduce the project's scope. "If Alan won't give you one egg, don't make an omelet."

4. Step 3: Set Up The Team

4.1. Flatten the Hierarchy

Most Interplay projects used a traditional hierarchy: producer at top, three leads (programmer, designer, artist) coordinating work. The GURPS/Fallout team tried a different approach — essentially no producer role in the traditional sense. Cain coded most of the core programming (hex-based isometric engine, combat routines, character skills) while overseeing other programmers. Leonard Boyarsky's art set the visual tone while managing three other artists. The line producer Fred Hatch handled internal coordination and external interactions.

4.2. Encourage Cross-Discipline Input

Everyone on the team should be encouraged to take part in multiple roles. Programmers and artists should feel free to add design ideas. Designers should suggest art styles or push coding boundaries. The final decision lies with the lead of that area, but implementing team members' suggestions is highly motivating. "People love to see their ideas come alive."

4.3. Physical Proximity Matters

Team offices should be near each other. Offices should be shared by people working on the same part of the game. Grouping designers with designers and artists with artists encourages idea-sharing and keeps designs consistent.

5. Step 4: Run The Team

5.1. Weekly Meetings

Establish a regular weekly meeting from the beginning. Early on, it serves as brainstorming and helps everyone get comfortable working together. Later, it becomes a forum for discussing problems where everybody can contribute.

5.2. Protect Uninterrupted Work Time

People need time to just do their own work. Unless it's very important, don't randomly call or drop in. Make it a habit to visit at predictable times — after lunch, first thing in the morning. Meanwhile, the producer must be available throughout the day to handle problems. "Yes, this is a double standard, but someone has to be available around the clock to coordinate the project."

5.3. Set Meaningful Deadlines

People work better toward milestones, but don't create phony deadlines for busy work or pressure. Make sure people understand why work needs to be done by a certain date. Good examples: "The dialogue needs to be done on Wednesday so we can start voice casting" or "that explosion needs to be finished next week so we can test combat."

5.4. Challenge People (The Hawthorne Effect)

The Hawthorne Effect — that people perform better when trying something new — can be used to your advantage. Encourage novel features, especially if the people suggesting them can implement those features themselves. People who see their own ideas in the game feel ownership, and once they feel that ownership, they strive to make the whole game great. "Nobody wants to be associated with a terrible game."

6. Watch Out For Pitfalls

  • Anonymous work: Some people like large groups because their work becomes anonymous. No one person is responsible for a given feature, so they hide and do little or low-quality work. Watch for these people — they destroy team morale.
  • Peer pressure: Good when it drives quality. Bad when it makes people feel like outcasts. Maintaining a healthy environment is the producer's responsibility.
  • Environment means more than hardware: It's more than good chairs and fast computers. Make friendly, constructive comments and keep the team cohesive.

7. Closing

Cain ends the presentation with a simple philosophy: "It is possible to work hard and enjoy yourself at the same time. Love your game, like your people, and have a good time. We're making games together, and that's supposed to be fun."

He notes the talk was well-received at an off-site producer meeting, then he was right back to work the next day. The GURPS license was lost about two or three months after he wrote this document — and the project became Fallout.

8. References