Characteristics of high-performing teams

This article was originally published in Game Developer Magazine. It was the second in a series of business columns that I am writing for GDM.

Spry Fox currently has several original f2p games in development, not including ports of our existing IP. Each game is being produced by wholly separate teams that are geographically dispersed, using different technologies and tools, under different contractual arrangements. And each team is compensated entirely via their future royalty; none are being paid cash in advance.

While we won’t know for a while to come whether our development strategy has been wise or flawed, we’ve already learned a great deal about the ideal composition of small, geographically-dispersed development teams. Some of our active teams have exceeded our expectations in terms of game quality and development time, while some are significantly behind where we expected them to be by now. A few of the characteristics shared (or not) by the high-performing and slower groups may obvious to you, and some may surprise you:

Clear and frequent communication

Our teams with a predisposition towards communicating more rather than less are getting much more accomplished. We’ve found that it is hard for a small team to over-communicate (as opposed to a huge team, which can easily become bogged down by too much pointless communication.) But it is very easy for a small team to grind to a halt when a solitary, isolated member encounters difficulties of any kind.

Takeaway: To some extent, communication risks can be minimized by scheduling regular meetings, encouraging a social atmosphere, etc, but in a distributed environment there’s only so much you can do, and if someone on your team is a hermit or lone wolf, you may be in trouble. You need team players who can communicate.

Rapid iteration

It’s common knowledge that rapid iteration is the key to “finding the fun” in any game development project aspiring to originality. However, our view on this has become relatively radical; we shoot for daily iteration. We’ve found that iteration times of even just a week (speedy for most larger studios) can hamper the progress of our projects. Iteration times of two weeks or more usually signal that a project is in severe jeopardy. There are exceptions to every rule (for example, sometimes it may be necessary to invest in technical infrastructure, which will temporarily slow down iteration) but in general we’ve found fast iteration to be vital to team success and morale.

Takeaway: It’s everyone’s responsibility to ensure that development is progressing in such a manner as to permit rapid iteration. Don’t allow the team to commit to a development path littered with the kinds of technical challenges that might cripple the iterative cycle. And don’t allow the team to become mired in the unexpected challenges that will inevitably arise despite your best efforts; find a creative way to work around them or change your design as necessary. Forward momentum is a small team’s best friend.

Commitment and reliability

Another characteristic of strong teams is that their members tend to be comfortable negotiating reasonable commitments and generally follow through on those commitments. While this should be obvious to anyone, the extent of its importance cannot be understated. We’ve found “reliability” to be the single biggest predictor of a team’s success; far above intelligence, passion, or experience in importance. A small team with a single unreliable member is in greater jeopardy than a team lacking all the other positive characteristics noted in this list.

Takeaway: Reliability is one of the most difficult characteristics to screen for in an interview. One of the major benefits of working with someone as a contractor, as opposed to full-time hire, is that you learn from experience just how reliable (or not) they are before making any major commitments to them. But whether you’re working with contractors or employees, helping people resolve the issues that make them unreliable — or gracefully parting ways with those who can’t be helped — will be one of your most important challenges as a studio manager.

Things a high-performing team does not need

Willingness to work long hours or to crunch — Not one of our high-performing teams has resorted to working unusually long hours for any period of time. We have already shipped four games without ever crunching, and this year we’ll ship several more without ever crunching. In fact, we have just one team that has ever engaged in anything even remotely resembling crunch; ironically and not coincidentally, doing so did not appear to actually move the project forward significantly. The phrase “work smarter, not harder” may be a Dilbert punchline, but in the game development world we need to hear it more often.

Shared location — As noted earlier, we work with people all over the world, from South America, to Europe, to Japan, to Australia. All of our teams are comprised of individuals who live nowhere near each other. What we’ve found is that a team with the positive traits noted earlier can easily overcome any challenge presented by such geographical dispersion.

Passion — Our industry is obsessed with the stereotype of the passionate indie, willing to work himself (or herself) to death in pursuit of a vision. But what we’ve found is that there’s a base-level of passion that almost everyone we encounter shares (why else would you even be in this industry?) and exceeding that base-level of passion simply isn’t necessary. Extreme passion, more often than not, seems to get in the way of compromise; specifically, the kinds of compromise that enable a team to function properly!

Wrapping up

It’s worth noting that the bar for team composition goes up when you switch from developing disposable single player content to f2p games with a real backend. The first four games launched by Spry Fox were all of the former type, and our transition to the latter has not been painless. We’ve found that even the most simple server-backed games can be exponentially more challenging to develop, especially when the team lacks some of the fundamental traits noted earlier.

Bottom line: when you transition from developing single player games to social or multiplayer games, and/or when your teams are geographically dispersed, character traits and team dynamics that were previously minor annoyances can suddenly become fatal. Watch out for poor reliability, poor communication and slow iteration: these things will guarantee that your game does not ship in a reasonable state of quality and/or within a reasonable period of time.