(This post was originally published on my personal blog.)
For many years around the turn of the century, some of us (myself included) used to believe that the best games can only come from big teams. We were tricked into thinking this because it was the status quo. The gatekeepers, who back then largely controlled what gets released to market, only considered specific kinds of games that met certain criteria - a growing list of "back of the box" features that the publishers and their marketers decided the market wants. In addition to implementing those features, game development teams had to push constantly improving hardware to its limits, and they had to feature a large amount of content to justify the $50-$60 price tag. Naturally, those games need big teams to make them. For big AAA games, team size has kept increasing on each subsequent hardware generation.
The revolution of digital distribution methods and the widening of the gaming audience brought on by Facebook and mobile games has changed all that and put the work of small teams into the spotlight. Freed from the tyranny of the traditional publishers, good small teams were able to focus on what really mattered to them, without having to check off any artificial bullet point features, and get direct support from players who were interested in their work. Very often, they were able to become critically and commercially successful exactly because they filled a gap that big productions could never fill. Yes, those games did not match all features of the big team games. Braid was only a few hours long. FTL didn't have any sort of multiplayer mode. Gone Home had no character models. So what? Smart small teams managed to turn their lack of resources into a strength by focusing on the one thing they needed to do well, and made their lack of features in other areas irrelevant.
The dynamics that brought the work of small teams into the foreground are not going away any time soon. Small teams will keep having avenues to talk directly to their fans about what's important to them - in fact, those avenues are likely to become broader and cover more platforms than before. This does not mean that their work is becoming any easier. With lower barriers, small teams are facing increased competition from everywhere and need to produce very high quality games to stand out.
My personal goal is to help such small teams stand out. In the past 15 years, I've worked in good and bad small teams and good and bad large teams. I worked on games that had anywhere from 5 to over 300 people on their credits. Some of the small teams (and even the large teams) were part of and interacting with a much larger organization. I have worked for companies that understand the power and advantages of small teams, and for companies that believe that big value can only come from big teams, so the only point of small teams is to one day grow to be a big team. Through various observations over the years, I am convinced that small teams, when structured properly, have massive advantages. There is, of course, a lot of personal bias in this. It is reinforced by prior experience that a good small team is more productive, more rewarding, and more fun to work in than a good big team. It's also reinforced by the kinds of games I like to play. Over the past few years, small teams have almost exclusively produced the kind of focused experiences I have time for. They have also given me the kind of unique experiences that big teams are too risk-averse to experiment with, like Papers, Please, and FTL.
Given my dedication to continue working with small teams, this is my attempt to start a list of factors that maximize the quality of such teams, specifically in games development. Many of these practices are not specific to small teams - they would benefit teams of any size. But as I'll explain in more detail, as the team size grows, so do the obstacles to implementing some of them. After a certain size, the practical obstacles can become insurmountable. Small teams need to understand that they are at a better starting point for implementing these guidelines and ensure that they take advantage of them. I've seen big companies spawn small teams that failed exactly because they were overrun by big team mentality. I've also seen developers leaving AAA who are stuck in the mindset of a big team, and fail to use the benefits of being small.
I plan to keep this list handy for teams I work with next, and update it as needed. I'm making an effort to keep the list realistic and achievable: everything I describe should be based on things I've seen work in practice in other great teams. If you have any feedback or further items to add to the list, please get in touch.
Great small teams hire and retain the right T-shaped individuals
Hiring good people is rightfully on the top of the list of any decent team, large or small. But the question of what good means deserves more attention than it's getting. I've seen many managers say "We hire the best in the world", without further explanation of what exactly that means. Without clarification, this declaration loses most of its meaning and creates confusion because "good" works on multiple, often conflicting levels, and no one is perfect at everything.
In their employee handbook, Valve describes the T shaped employee, which is a great starting point when discussing any staffing needs. The horizontal part of the T represents all areas an individual is interested in and knows something about (not just areas related to game development). The vertical area is experience and knowledge in their specific discipline.
Framing the discussion in terms of the T shaped person immediately reject two kinds of people who may have otherwise been mistaken for "the best in the world":
- someone super-skilled in their own discipline that does not understand anything else, including what kind of game you are making, and ends up isolated from the team, creating art, software or content to match their own idea of how to advance their discipline, often at the expense of the game itself
- someone who knows a little bit about any topic mankind knows about, but not enough to contribute anything concrete
The horizontal part of the T is critical for a small team. Because there are fewer people on the team, you need good coverage and overlap among the disciplines. Practically speaking, determining someone's quality and skills at the vertical part of the T (the skills in their specialized area) is very easy compared to determining their fit for the horizontal part. If you are in a small team and you are finding you are spending most of your interview time on evaluating specialized skills, that's a bad sign.
Nobody is a perfect T. Some people will have developed either the horizontal part or the vertical part more. The quality of the vertical part will vary even among very competent people. The range and depth of the horizontal part will also vary widely. There is no hard and fast rule about what kind of T shaped employee will make the best contribution to your small team, because the best fit heavily depends on context. What kind of game are you creating? What kind of business model? What type of players are you trying to appeal to? How will the game be updated and evolve over time? What kinds of areas is it likely to expand to? What kind of developer will be interested in developing and playing this kind of game in the long run? What kind of specialized skills do you really need, and at what depth? All these and a million other questions will affect the impact different people can make on your team. Defining them and discussing them openly both with existing and potential employees is critical.
Having the right individuals on the small team matters more than job titles. Whether they have informal job titles or not, good small teams know that everyone contributes wherever they can, depending on the project needs at the given time. Because they have developed the horizontal T part, they understand the ins and outs of all other disciplines, always see the big picture, and can sometimes jump between disciplines. An artist may become a tester on the few weeks before release when all content is complete. A server programmer may become a designer during a quiet period where all services are working as intended. And because all team members are primarily motivated by the kind of game they are making, they always contribute meaningful discussions on the experience the game offers and how it can be improved.
It’s one thing to hire the right people on the team, and another to retain them in the long run. Many of the following guidelines apply both to getting the most out of individuals, and creating an environment that can keep them happy in the long run.
Great small teams rely on trust, not process
In their Culture presentation, Netflix described the introduction of Process as a management tool to control complexity when the team size increases. An assumption is that as team size grows, the percent of high performance employees is often decreasing (red arrow in the graph below). This is true more often than not, as the pressure to grow often results in sub-standard hires, and high performance T-shaped employees are at least an order of magnitude harder to find than the average employee. As this diagram demonstrates, at some point the percentage of high performers isn’t high enough to manage the complexity.
At that point, Process becomes the middle manager’s favourite tool to manage team growth. As mistakes start to happen, process is formed around those mistakes to try and reduce damage and inefficiencies. Examples of such process can be:
“You need to get approval from X and Y before starting to work on feature Z."
"Every morning at 9 AM you have to attend a stand up meeting."
"Every code checkin has to go through a code review."
"You can never do any project related work from your personal laptop."
"You must attend this all day legal presentation."
"You have to work at least 8 hours a day and take no more than 5 weeks of vacation a year."
The problem with this kind of rigid process is that it's focused on reducing damage to the team from bottom performers or untrustworthy people, at the cost of increasing barriers and friction for the top performers to make unexpected positive impact. This is the exact opposite of what it should be. A basic principle of performance and productivity management is that the biggest impact will come by taking advantage of one's strengths, not eliminating their weaknesses. The same applies to a team.
A great team hires good people not because they can perform X amount of work in Y amount of time, but because they can bring good judgement and unexpected positive change. I have seen good people who needed to go against process in exceptional circumstances in order to bring positive change to the project. Even in the cases where they managed to do it, having their good judgment second guessed all the way through takes its toll. Teams frustrate, demotivate and lose good people that way all the time.
Instead of formal process and rigid rules, good small teams rely on trust. Hiring good people brings good judgment, and it would be foolish to throw that away by establishing rules everyone has to follow blindly. If you are finding you need to have process and rules similar to the above on your small team, take a moment to think who exactly you need the rules for, and if they're worth the extra hassle to hire or keep around.
Great small teams avoid unneeded complexity, or eliminate it very early on
There are many forms of complexity on any project of any size. Because some complexity is always needed depending on the game type and the project's needs, it's easy to resign to its existence and call any signs of complexity a "necessary evil." But good teams manage to have orders of magnitude less complexity than other teams of the same size. And good small teams manage to have so little complexity that they can produce results in speeds many big teams think is humanly impossible.
By definition, a small team understands and avoids the complexity that comes from a large team – even a large team consisting exclusively of capable people. Going through a lot of stakeholders, managing the communication channels, ensuring everyone has something to do, all these things slow progress down and diffuse focus.
Being resource-constrained, as small teams often are, is a blessing in disguise for maintaining laser-sharp focus. Small teams have to figure out the most important features of their game, validate them quickly, and focus exclusively on revising them as many times as they need to. Having unrealistic scope or allowing feature creep is less likely to be a problem for a small team, as long as the team is good enough to realize the best use of limited resources is to assign them on a narrow area where they can make the most impact, and avoid unnecessary exposure to other areas.
Perhaps I’m biased because of my tech background, but I believe tech complexity to be one of the most dangerous types of complexity on a games team. That’s because regardless of their other skills, non-technical people do not and cannot react efficiently to its existence. A bad technical director saying “I know this slows down the team, but it is what it is,” followed by some incomprehensible technical terminology, is enough for the most capable project manager to resign without further questions.
One of the most defining moments in my career as programmer was witnessing the unreasonable complexity around online systems in a big games company. Conceptually simple systems like account management, achievements, and matchmaking ended up horribly over-engineered, slow and unstable. The (relatively big) central team that was supposedly helping game teams implement and host online services ended up becoming an obstacle: It would have been far easier, cheaper and faster for individual game teams to separately implement their online services on AWS or something similar. But the big team was completely resigned to the existence of this complexity. An unreasonable amount of programmers had to be deployed working on game-specific online services, even with the existence of the central team that was supposedly helping. I kept hearing the phrase "this is how enterprise software works" so often, I started thinking maybe it was actually true. I had to actually see a small team that had implemented the same services in a far less complicated manner and in a way that allowed the team to iterate on them with a small fraction of the people in the big team, to fully appreciate the power of uncomplicated technology to amplify the efforts of small teams.
There’s a common property about most types of complexity. Once allowed to creep in and grow, it's very hard if not impossible to eliminate without extreme pain. Large teams won't become small teams. Complex technology won't simplify itself. The people who are emotionally invested in their features and have been working on them for months won't like to hear they are all being cut. Small teams know this, and consider the long term complexity implications of every decision they make. They are also on the lookout to identify emerging complexity and make it a priority to root it out.
Great small teams are primarily motivated by passion for the game they are making
What are the primary motivators that cause your fellow developers to come to work every day? By primary motivator, I mean something that would cause them to quit if it ceased to exist. Obviously, for many people salary is one. Other primary motivators can include a passion for one's discipline (creating great art or greatly architected software), recognition and feedback from the fans, or simply habit (not knowing what else to do with one's time).