Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
When they set themselves up appropriately, small game teams can move with flexibility and speed that's impossible for large teams.
(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.
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.
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.
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 actuallysee 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.
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).
In any team, having members who do not have "passion for the game we are creating" in their primary motivator list is a cause for concern. This is very easy to determine: are the developers playing the game as they make it? Would they be playing it even if they were not working on it? Would they quit if you suddenly changed the game type to something they are not excited to play themselves?
Because of extreme specialization and the need to staff up, big teams measure that kind of engagement in percentages well below 100%. It's not uncommon to have big teams where the number of people actually excited about and playing the game is 50% or less. Small teams have the unique advantage where it is actually possible to have that percentage be exactly 100%. It’s far more likely to find and maintain a team of 5 people building a game they are passionate about, than it is to find and maintain 100 such people. And because of the increased sense of ownership, people who are drawn to small teams are already more likely to have that kind of passion to begin with.
Teams where everyone is primarily motivated by a passion for the game enjoy unique advantages. Bad politics (i.e. individuals pursuing personal interests at the expense of a project's interests), are far less likely to materialize compared to teams where some members are primarily driven by personal goals. Team members respect each other, even through disagreements, because they know everyone has the good of the game as their primary goal. Planning and executing many of the features doesn’t need any formal process because all team members have an understanding of what makes the game enjoyable, so there is often agreement on what needs to be done next.
Good teams can also distinguish between a healthy passion and obsession. Often in the industry the term "passion" is abused to subtly force people to crunch or work for less money. But people who are obsessed and only live to play or work can never develop a healthy horizontal part of the T, hence are not good team members despite their passion.
Most big teams compartmentalize sensitive information on a "need to know" basis. There are many reasons for this, some of them legitimate. For example, public companies have legal obligations that make it extremely hard or impossible to share financial details in real time.
Good teams always use important information to inform all kinds of decisions. Financial and product usage information, especially broken down in regions and demographics, is one such important piece of information to understand the reach of the game, who plays it and why, and how that's changing over time.
But there are other advantages to the open sharing of information, beyond this obvious one. Good people who are entrusted with sensitive information feel more ownership in the company and the product. They feel like trusted co-owners instead of pawns who get told what to do without having the full big picture. They do not make up stories about how successful or not the company is based on rumours they heard around the water cooler.
There is no excuse to not share this kind of data in a small team. The risk from potential leaks is small. Small teams intentionally share or have information leaked all the time, and they still manage to stay in business. The bigger risk is blindfolding the people on your team, giving them a reason to mistrust you.
There can be a lot of sources of outside intervention for a small team. If it's part of a big company, executives may want to intervene for many reasons. If it's externally funded, the investors may decide the best chance of getting their money back on the desired timeframe involves them making some decisions for the team.
Being shielded from such external intervention allows the team two fundamental advantages: permission to fail, and the ability to focus on long term benefits. And because a good team is made up of capable, passionate people with good judgment and intimate knowledge of the game, there is no better outside authority for deciding how to pursue the long term benefits.
Making games is certainly risky. Smart teams know that. They also know there are techniques to turn the odds in their favor. But like any field where there is uncertainty and risk, those techniques involve failing, frequently more often than succeeding. The last thing a good team needs is having the threat of termination or other side effects each time things don't work out. If they are in such an environment, that would affect the quality of the work of the team and, as a result, make it similar to the work of big teams: risk free, boring, and still likely to fail.
There are also strong factors that can pressure teams into sub-optimal decisions that bring short term benefits, at the cost of losing bigger long term benefits.
Financial pressure can easily force a team to release a game before it's ready, bringing in revenue a bit faster at the cost of longer term loss of reputation, goodwill and revenue.
Crunch might become a compelling argument for making the milestone right around the corner, at the cost of frustrating and burning out good employees who won't stick around in an environment that makes such poor decisions.
Certain patterns of data-informed decisions are also short term boosts at the cost of losing longer term benefits, and they are particularly dangerous, because people wielding data usually end up gaining credibility with detached executives who don't have a long term view of the game. In the dawn of Facebook social games, good small teams knew that spamming one's friends for progression was a bad idea in the long term, despite what all the numbers back then said.
Good small teams have leadership that sets up the team in a way it can take creative risks while reducing the risk of catastrophic failure, and set up a long term view that's not distracted by fake short term benefits. In the process, they also shield the team from outside intervention that could mess all of this up.
This may seem at odds to the previous point, but it isn't. While direct outside intervention is bad, having a good ecosystem that provides advice, help or resources as needed is important. The key point is that such help is needed and welcomed by the team and is not masquerading as help in order to exert control over the team externally.
Even if they have great T-shaped people, small teams usually don't have the diversity of good bigger teams. Feedback from people with a more detached view is limited. Or perhaps despite the skilled people on a small team, there's simply not enough of them to cover a specific area of expertise and they need outside help. While it's always possible to hire temporary outside help or council, it's far better to have such help available at any given time. The best small team I've seen was part of a bigger company with a deep bench of talent. Even though the team was completely independent, it would regularly receive outside feedback that the team recognized as extremely helpful and would regularly incorporate into their product.
Being part of a bigger company is not the only way for a small team to be in a useful ecosystem of external support. Certain indie companies and teams have very healthy attitudes of helping each other, sharing ideas, feedback and expertise, which can have a similar effect.
Read more about:
Featured BlogsYou May Also Like
