Team Size

tim-cain production team-size game-development management specialization

Abstract

Problem: How does team size affect the process of making games, and what are the trade-offs as teams grow larger?

Approach: Tim Cain draws on decades of experience across teams ranging from 3–4 people to nearly 200, covering trends from the 1990s through the 2020s.

Findings: Larger teams enable bigger, more polished games with deep specialization, but introduce exponential communication overhead, higher costs from small mistakes, reduced team familiarity, and growing production burden. Smaller teams offer the inverse trade-offs.

Key insight: Given the choice, Cain would prefer a smaller team working over a longer period — you get the advantages of tight communication and trust without the compounding costs of scale.

Source: https://www.youtube.com/watch?v=gC0KWoK5XhA

1. Tim's Experience with Team Sizes

Tim has worked on teams as small as 3–4 people and as large as nearly 200. He defines "team" as the in-house development group — not contracted-out localization, box art, or other external work. His career tracks the industry trend: teams averaged in the high teens to 30s during the 1990s, grew through the 2000s, and by the 2010s regularly hit 50–80 people.

2. Advantages of Big Teams

2.1. You Can Make Big Games

Some genres simply require large teams. Long, detailed RPGs with modern art expectations, MMOs (with networking, data servers, security, subscription services), and games-as-a-service titles all demand sustained large-scale effort. You can't shortcut this with a handful of people.

2.2. Specialization

Bigger teams allow for deep specialists: a programmer who only does lighting or pixel shaders, an artist who only lights levels, a designer who focuses exclusively on how guns feel frame-by-frame. Writing has evolved from "someone on the team also writes" to dedicated narrative designers specializing in dialogue, lore, cinematic scripts, or even ad copy. Dedicated community managers become feasible — invaluable for conventions, Q&As, and forum management.

2.3. Spreading the Work

"More hands make less work." Difficult tasks can be broken down across multiple people, and drudgery work gets distributed so no single person is stuck with all of it.

2.4. Faster Output Through Staging

Big teams enable staggered production pipelines. While one game enters bug-fixing, concept artists can start pre-production on the next title. People shift between projects as each phase needs more or fewer hands — concept artists early, large art teams in the middle, fewer at the end. This lets studios hit console cycle windows (8–10 year lifecycles, 3–4 year dev cycles).

3. Disadvantages of Big Teams

3.1. Communication Overhead Is Exponential

The difference in coordination burden between a 10-person team and a 100-person team is not 10x — it's exponentially larger. More meetings, more emails, more documentation, larger task and bug databases. Keeping all parts moving becomes its own massive challenge.

3.2. More Production Staff, Less Content Creation

You need more producers to manage the growing complexity — tracking tasks, estimates, bugs, localization. These production roles are essential ("they let all of us make the game"), but they don't generate game content themselves. The ratio of overhead to output shifts unfavorably.

3.3. Reduced Familiarity and Trust

You can be close friends with 2–3 people, loose friends with 20–30, but past 50 there will be teammates you literally don't know. This breeds misunderstandings (someone thought X was being handled, but it wasn't) and mistrust (a designer doing deep thinking looks like they're doing nothing to an unfamiliar observer).

3.4. Small Mistakes Get Magnified

This is what Tim identifies as probably the biggest problem:

  • Script format changes: A small game might need a day to redo all scripts. A big game? A month with multiple people.
  • Adding a new language: A small game has 10–20K words — no big deal. A big game has 500K–1M words. Some languages require new fonts, genderized nouns, honorifics based on NPC social class (Tim references his experience with Arcanum's generated dialogue).
  • Estimation errors: A 10% misestimate on a small game might cost $10–50K. On a big game, that same percentage error means $1–10M — and that money has to come from somewhere.

3.5. Distributed Teams Add Complexity

Tim notes working on projects with teams spread across the US, Europe, Asia, and Australia. Even scheduling a meeting becomes a logistics problem. His 5 AM wake-up habit has led to 7:15 AM meetings to accommodate global time zones.

4. Tim's Preference

If given a bag of money and told to make whatever game he wants, Tim would choose a smaller team over a longer period of time. You get the advantages of tight communication, trust, and low overhead, while the extended timeline allows you to potentially match the scope of what a bigger team could produce faster.

He acknowledges this isn't always possible — sometimes the project simply demands a big team. And he notes that introverts tend to prefer smaller teams for the reduced communication overhead, though big teams can have pockets where individuals don't need much interaction. There's room for everyone on every team.

5. References