Onboarding New Team Members

team-management onboarding game-development leadership pipelines guidelines

Abstract

Problem: How do you bring new hires up to speed on a game project, especially as teams, pipelines, and the sheer volume of games have grown?

Approach: Tim Cain reflects on decades of experience integrating new team members — from small 80s/90s teams where cohesion was natural, to modern large-scale projects with long asset pipelines and corporate terminology.

Findings: Effective onboarding relies on leads actively reviewing work early in the pipeline, written guidelines per discipline, examples of existing in-game work, and curated reference material (games, movies, books, TV shows) that new hires experience during work hours. However, onboarding must not squash fresh perspectives — new hires see the game with fresh eyes and may bring ideas that improve or challenge existing constraints.

Key insight: The goal of onboarding is consistency without rigidity — align new members on the vision while staying open to ideas that only an outsider's perspective can provide.

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

Why Onboarding Feels Like a Bigger Deal Now

Tim notes that "onboarding" as a term is relatively new to game development — borrowed from corporate culture in roughly the last decade. The underlying practice of bringing people up to speed has always existed, but several factors have made it harder:

  • Larger teams make natural cohesion difficult. On small teams, everyone organically knew what was being built.
  • The explosion of games (Steam alone sees ~25,000 titles per year) means you can no longer reference a game and assume everyone has played or even heard of it.
  • Longer asset pipelines mean feedback loops are much slower. A death animation might depend on a model made months or even a year earlier, so problems surface late.
  • In the 80s and 90s, assets were made quickly. New additions were noticed immediately ("that wasn't there yesterday"), making feedback fast and natural.

Methods for Bringing People Up to Speed

Use Your Leads

Leads should be watching what their people produce early in the pipeline — catching issues with mesh density, rigging, or design direction before months of downstream work are built on top. This only works if leads are aligned with each other. Tim notes he's worked on games where the lead artist, lead designer, and lead programmer were "not all making the same game," which is a serious problem.

Written Guidelines Per Discipline

Each discipline gets its own guidelines, and they're wildly different from each other:

  • Code guidelines cover naming conventions, object structure, with example objects from the actual game.
  • Narrative guidelines define character voice, quest structure, and specific rules (e.g., "no more than five player responses per dialogue node"), with examples.
  • Art guidelines reference movies and stills to establish the visual target.
  • Level design guidelines explain line-of-sight philosophy, points of interest (POIs), and reference levels from other games.

Tim appreciated the move from paper documents to tools like Confluence, where you could embed images and video — showing people the target rather than describing it.

Curated Reference Material

Teams commonly assign new hires specific games to play, movies and TV shows to watch, and books to read. On modern projects, new hires are given dedicated time in their first week or two to consume this material at work — it's treated as part of the job, not homework.

Tim adds a practical side benefit: when press inevitably asks "what were your influences?" (which he considers the most generic interview question possible), every team member already has their answer from onboarding.

Existing Prototypes and Vertical Slices

Depending on when someone is hired, the team may already have playable material:

  • A prototype demonstrating system mechanics
  • A beautiful corner showing finished art in a level
  • A vertical slice — a complete level at near-shipping quality across mechanics, layout, narrative, and art

These become powerful onboarding tools that let new hires experience the vision directly.

The Risk: Don't Squash New Ideas

Tim's most emphatic point: onboarding exists to create consistency, but it must not create rigidity. New hires bring the most valuable thing on a project — fresh eyes. They may:

  • Notice problems the team has accepted as "just how it is"
  • Reference a UI pattern or AI behavior from a recent game that solves an existing issue
  • Challenge specific constraints (like the five-response dialogue limit) in ways that improve the game

Guidelines should be "a lot of examples with an overarching coherent rule" rather than rigid mandates. Even when a constraint exists for practical reasons (UI limitations, tool restrictions), a new hire questioning it may prompt the team to re-examine whether it's worth relaxing — if not in the current game, then noted for the sequel.

On Corporate Terminology Creeping into Game Dev

Tim opens with an amused observation about terms migrating into game development from business: "onboarding," "ARPU" (average revenue per user), and "bespoke." He notes that "bespoke" only became necessary as a term once most things stopped being handmade — when everything was custom-built, there was no need for a word distinguishing it. Now that engines, sound libraries, and tools come off the shelf, the small amount of custom work is the "bespoke" part.

References