26 Feb 2010
Virtual Team Game Development
In my latest role, I am working remotely and managing a totally virtual team. I was fairly skeptical about this before I agreed to join the project, because I know firsthand the importance of face time with your team. After all, producing a game is a lot more than simply collating status updates and checking off tasks on a tasklist. Your ability to communicate is critical. Ad-hoc conversations between team members (especially cross-discipline) are often incredibly important — nobody’s going to email you notes from those discussions, and if you miss them, you may have missed a great new idea or toxic miscommunication that will come back to haunt you later.
At the same time, a producer has to know when to communicate. Bonding with the team, listening to their concerns, even shooting the bull at the water cooler are important and necessary, but every hour you spend talking is an hour you spend not doing — likewise with your team. You can have the tightest group of ninja developers on the planet who get nothing done but talk if you’re not careful.
So how can a producer manage a team virtually? Isn’t this a recipe for disaster?
So far, it turns out that it doesn’t have to be a disaster, but it is a huge shift from everything you’re used to. Here are some best practices for remote production:
- Team size may be the single biggest determiner of success in this kind of endeavor.
This is probably not very surprising. Since team size plays into your scope as well as how much it’s going to cost to complete, you want to keep the core team as small and ninja as possible. Not only does additional headcount increase burn rate, but it also slows down decision-making and iteration. It is almost always better to have fewer people for longer, than more people for less time. Sadly, most publishers would disagree with that position, doubly so if you think you’ll miss the quarter.
Naturally a smaller team probably means a smaller scope. This is not a coincidence
- You need a multidisciplinary team. Emphasize broadness over depth of expertise wherever possible.
This goes hand-in-hand with #1, but if you’re keeping headcount as low as possible, you really cannot afford the luxury of a team comprised of specialists who can’t help you with brute force gruntwork. At the same time, you will certainly need experts in specific areas. Be judicious where you spend your personnel XP. - The 9-to-5 (or more likely, 10-8) as you know it is over. Track results, not effort.
This is a really, really big thing to adjust to, and even harder to train a team to do. If people are working from home, don’t expect them to be chained to their computers every waking moment of the day. They will have distractions. Real life will deign to intrude on your project in their mental to-do list. Spouses, children, and pets don’t necessarily care that it’s officially “work time” — all they know is the person they’re looking for is home and accessible. This can be a great selling point, of course — what better for work/life balance than to be able to see your kids every day during work?The trick is to focus on results, not effort. Don’t be concerned with ensuring your team’s collective butts were in their seat for 8 hours yesterday, be laser-focused on when systems and assets will be finished. Much has been written about this style of management and how hard it can be to implement in a 9-to-5 culture, but a virtual team is a great context for this kind of philosophy to take root. - Minimize Rabbit-Hole Depth.
What I mean by this is to make sure nobody on your team can go off on a task and waste a week working on the wrong thing. Because you’re not engaging in “face time” with your team, and because nobody is walking around noticing obvious problems, you need to make sure you avoid rabbit holes, or at least avoid deep ones. Employ agile processes like daily “stand up” calls to get this kind of information flowing on a regular basis, and focus on getting to Always Playable Build status as soon as is reasonable. - Make extensive use of communications tools, but pick your battles.
I’ll cover specific tools more in-depth in a seperate post, but this is critical (and rather obvious). No face-to-face meetings? Skype or conference call. Overcommunicate via email and use extensive filtering. Require mandatory IM availability (and allow DND mode as needed for productivity’s sake). Use wikis rather than Word documents.
However, just because you HAVE communication tools that can pierce the veil of virtual solitude does not mean you should be cavalier with how you use them. Constantly IM’ing and intruding on your team members and causing context-shifting during their work day is no less irritating and productivity-killing on a virtual team than on a physically colocated one. In fact, it may be more so, assuming that their own workspace may be subject to built-in distractions that an office environment may not (family members, a fully stocked fridge, the temptations of ESPN, etc.)
Finally, there is no substitute for a face-to-face meeting, so budget for them and plan to hold them at critical points (kickoff, beta, pre-launch, etc). It is important to put faces and real people to the names one sees in a project file or IM list. It reduces the chance of teammates jumping to irrational conclusions about motive and helps to build a sense of team unity in attacking a common goal.
I’m producing Beakiez (http://beakiez.com) with a remote team, and I’ve found skype group chats and skype video crucial to the process. Skype video in particular is golden. In addition to being great for facetime, it means I can check out a build by looking over a dev’s shoulder at his screen, as opposed to having to set it all up on my end.
Dave Taylor
July 8th, 2010 at 5:04 pmpermalink