Characteristics of high-performing teams

Good team.

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.

6 responses to “Characteristics of high-performing teams

  1. Thanks for sharing your experiences, David. Looking forward to hearing more about your projects and finding out which ones jump ahead of the pack as far as F2P fiscal sustainability is concerned.

  2. You don’t pay people? You also don’t write code and you don’t do art. In what sense do “you” have several games in development?

  3. David J Edery

    @? — Danc has actually created the art for several of our games. 🙂 That said, I’m sure he’d object to the implication that the role of game designer is irrelevant, even if you happen to believe that art production and programming are the only things that actually matter. And the business aspects of monetizing and distributing a game successfully are a place where the average independent game developer trips up in a big way. There are a great many games out there created by competent artists and competent programmers that nevertheless fail miserably.

  4. Your list is good. It’s hard to argue that reliability, communication and rapid iteration are bad things. But how do you achieve all of those things? Can you let us in a little on how you encourage these qualities in a team and what you guys do to foster a trusting relationship based on mutual respect? (I am a developer myself and my interest is piqued).

  5. David J Edery

    @aeiowu — I wish I could say that we have this down to a science, but the truth is that we’re learning as we go. We’ve made plenty of mistakes and we’ll make more still.

    For communications, we’ve recently begun trying to increase the frequency of our voice chats with each dev team (it has been too easy to slip into an “all IM / all email” mode of operation) as well as the “quality” of our chats by using group video conference; the Hangout system in Google+ is fantastic for that. Now that we have some revenue coming into the company, we’ve also been thinking about scheduling a few trips to meet up with each team in person, though that remains somewhat challenging given how extremely dispersed we are, geographically. And crucially, for all our projects, we maintain a *very* detailed design/iteration/playtesting log that helps to keep everyone on the same page. Danc has written about that here:

    Reliability… that’s a very tricky one. We try to keep our development plans lean so that we never overburden a team. Better to release something slightly less polished or feature-rich rather than cause a breakdown (in which case, it’s not “the developer was unreliable”, but “we asked too much of the developer and it blew up in our face.”) But really, there’s so much more to this. Some people simply aren’t reliable. Some reliable people can quite suddenly become unreliable in specific circumstances that vary from person to person. Sometimes the most reliable person can be sideswiped by nastiness in life that is absolutely not their fault, and its your obligation as a good partner to help them through it. How you sort through all that and manage it as best you can is a topic for an entire book, not a comment on a blog post. And I’m certainly not qualified to write that book — I still have a lot of learning to do.

  6. David, very good article! Sounds like you guys are doing a fine job in running a “tight ship”. I definitely see from the additional responses in the comments that you admit that mistakes are made and courses are corrected. Sometimes that correction and continuous improvement is the hardest part of having a good team. You gotta have everyone be in that mindset to make things work.

    One of the hardest things I’ve ran into is having designers who don’t code and programmers who don’t design work together well. What are your thoughts on this? Typically the situations I’ve ran into is where the designer has some grand idea of what the feature should be like and the programmer has little room to negotiate and collaborate in that design. And sometimes I get that a group of designers come up with something and hand it off to a group of programmers to implement it. Neither of those sound like teamwork to me. 🙂

Leave a Reply

Your email address will not be published.