Tyler Brooks
Someone just accepted your offer. They start Monday. The game launched eight months ago, it’s got 200,000 active players, three live events running in parallel, a hotfix due Thursday, and a Confluence wiki that hasn’t been touched since beta. Congratulations. You now have approximately two weeks before this person either clicks into gear or quietly starts wondering if they made a mistake.
Most onboarding advice is written for greenfield projects. Clean slate, fresh repo, nobody’s production is on fire. Live games are a different animal entirely. The codebase is scar tissue. The processes evolved under pressure. Half the “why we do it this way” knowledge lives in the heads of three people who were there during the Week One Crisis. Getting someone up to speed without dropping the ball on live ops is one of the hardest producer challenges there is, and most studios treat it like a checkbox.
Build a Live Game Context Document Before They Arrive
Don’t wait for day one. Before your new hire logs in, create a single living document that answers the questions they’ll be too embarrassed to ask: Why does the economy system work this way? What happened with the Season 2 rollout? Who actually makes the call on emergency hotfixes?
This isn’t a wiki dump. It’s a curated narrative. Three to five pages covering: the game’s current state by the numbers (DAU, retention curve, revenue trend), the five decisions that most shaped current architecture, the political landmines (that integration your lead engineer hates but the publisher requires), and the communication channels that actually matter versus the ones that exist on paper.
In my experience, new hires spend their first two weeks reverse-engineering context that five people in the room already have. Write it down once. Save everyone the time.
Define a 30/60/90 Plan Built Around Live Cadence, Not Generic Milestones
| Onboarding Phase | Duration | Primary Activity | Ownership | Deliverable |
|---|---|---|---|---|
| Shadow Mode | Days 1-7 | Attend standups, live ops reviews, incident calls | New hire observes only | Written questions become documentation |
| Contained Ownership | Days 8-30 | Own one small, low-risk deliverable | New hire drives | Minor balance pass, localization QA, or content update coordination |
| Recurring Responsibility | Days 31-60 | Take on one recurring task with backup | New hire leads, senior staff loops in | Weekly release checklist or similar process |
| Full Accountability | Days 61-90 | Own core role with clear escalation | New hire fully responsible | Independent decision-making with defined backup |
Generic 30/60/90 plans are useless for live games. “Learn the codebase by day 30” means nothing when a content patch drops in week two.
Structure the plan around your actual release cadence instead:
Days 1-7: Shadow mode. They attend every standup, every live ops review, every incident call. They don’t own anything. They ask questions in writing so the answers become documentation.
Days 8-30: Own one small, low-risk deliverable end to end. Not a feature. Something contained: a minor balance pass, a localization QA cycle, coordinating one content update through the pipeline.
Days 31-60: Take on one recurring responsibility with a backup. They run the weekly release checklist. You or someone else is still in the loop, but they’re driving.
Days 61-90: Full accountability on their core role. Escalation path is clear, they know who to call, and you’ve had at least two explicit feedback conversations.
The key distinction: every milestone should be tied to a real deliverable on your existing roadmap, not a hypothetical learning exercise.
Pair Them With the Right Person, Not Just an Available One
Buddy systems work when the buddy is chosen deliberately. The person with the most tenure isn’t automatically the right pick. You want someone who communicates well, has patience for questions, and isn’t carrying a 60-hour week right now.
On live projects, also consider rotating shadowing. Have your new hire spend two days each with the engineer who owns the backend, the live ops lead, the community manager, and the QA lead. Not to learn everyone’s job. To understand the dependencies and friction points before they accidentally create an incident by not knowing that “approved for deploy” and “safe to deploy Friday afternoon” are not the same thing.
Establish Incident Awareness Early, Not After the First Incident
New team members on live games will eventually be in the room when something breaks. If you haven’t prepared them for that moment, the first real incident is going to be a terrible experience for everyone.
Run a tabletop review of a past incident during their first two weeks. Walk through an actual postmortem: what broke, how it was detected, who was called, what the communication chain looked like, what the player-facing impact was, and what changed afterward. Real examples beat any process document.
Also be explicit about escalation thresholds. What severity warrants waking up the technical director at 2am versus handling it in the morning? New producers often either escalate everything or, worse, try to handle something silently because they don’t want to look like they can’t manage. Clear thresholds eliminate both problems.
Recommended Tools to Support Live Game Onboarding
A few things that actually help:
Project management: Jira with a dedicated onboarding epic linked to your live roadmap. HacknPlan works well for smaller teams who find Jira overkill. The point is that their tasks live in the same system as everyone else’s from day one, not in a separate “training” silo.
Documentation: Notion or Confluence for the context document. If you’re on Confluence already, create an “Orientation” space separate from your main wiki. It signals that someone thought about them specifically.
Knowledge capture: Loom for async video walkthroughs of complex systems. A 10-minute screen recording of how the content pipeline works beats a 40-page doc.
Books worth assigning: The Art of Game Design by Jesse Schell for design philosophy grounding, and Agile Game Development by Clinton Keith for understanding how sprint cadence applies to live ops specifically. For producers who are also managing people dynamics on a tight team, The Making of a Manager by Julie Zhuo is genuinely practical.
Courses: Game Production Fundamentals on Coursera and Riot Games’ free GDC talks on live service production (available on YouTube) are solid for context-setting without pulling senior staff away from their actual work.
The new hire who becomes your best team member in year two is usually the one who had a structured first 90 days. It’s not complicated, but it requires someone to actually own the onboarding process the same way they’d own a feature launch. Assign it, resource it, and treat it like it matters, because on a live game, a bad start doesn’t just hurt one person. It affects everyone who has to pick up the slack while they find their footing.
