Priya Sharma
The new developer starts Monday. You’ve sent the calendar invite, added them to Slack, and told yourself you’ll figure out the rest when they get here. I’ve watched this exact scenario play out at studios of every size, and it almost always results in the same thing: a talented person spending their first two weeks confused, underutilized, and quietly wondering if they made a mistake accepting the offer.
Onboarding in game development is genuinely harder than onboarding in most other software industries. You’ve got custom engines, proprietary tools, years of accumulated tech debt with no documentation, art pipelines held together by a single person who “just knows how it works,” and a codebase that would make a senior engineer at a fintech company cry. Getting someone productive fast is not just a niceness, it directly affects your schedule and your budget. A mid-level developer earning $90k who spends three weeks flailing costs you real money and real morale.
The First Day Is Not About Productivity
Here’s what most people don’t realize: the goal of day one is not to get anything done. The goal is to make the person feel like they belong and give them enough orientation that they can start absorbing information effectively.
I’ve seen studios hand a new engineer a laptop, point them at a 40,000-word Confluence wiki, and say “read through this and ask questions.” That’s not onboarding. That’s hazing with documentation.
Instead, give them a single, curated reading list of no more than five documents. A project overview deck, a current sprint board walkthrough, a glossary of studio-specific terms (every studio has them), a map of the codebase or asset directory structure, and contact list with roles. That’s it. Five things. The rest of the wiki exists when they have specific questions, not as a pre-req.
Pair them with a buddy, not their direct lead. The buddy relationship works better when there’s no performance evaluation dynamic. Make it someone one or two years into the studio who remembers what it felt like to not know things. I’d pick a mid-level on your team over a senior every time, because seniors often forget what “confused” feels like.
Build the Onboarding Environment Before They Start
The single biggest time sink in onboarding a developer is environment setup, and it’s almost entirely preventable.
Get their machine provisioned and their accounts created before their first day. I know this sounds obvious. Studios still routinely fail at it. I worked with a studio of 40 people where a new engine programmer spent four days in their first week just waiting on IT access and installing SDKs. Four days. On a 12-month project with 8 developers, that’s real schedule impact.
The thing that actually works is a maintained onboarding build. One person on your team (usually whoever owns your build pipeline) keeps a branch or build specifically for new developers. It’s clean, it builds successfully on fresh hardware, and it has a README that covers setup from zero. Not from “you probably already have these tools installed” zero. Actual zero. You update it every time you change a major dependency or tool version. I’ve made this someone’s explicit sprint task at multiple studios and it pays for itself after the first hire.
Tools worth having: a proper internal wiki (Notion and Confluence both work, Notion is honestly easier for smaller studios), a recorded studio orientation video for async teams, and a short “get the game running” checklist in something like Linear or Jira where the new person can actually check off progress. That last one matters more than it sounds. Checkboxes create momentum, and momentum is what you need on day one.
The Feedback Loop Nobody Sets Up
Jobs in Game Development [Team Management] · Masahiro Sakurai on Creating Games on YouTube
Most studios give new developers tasks right away but no structured feedback until the 90-day review. That gap is where problems fester.
Set a 1:1 at the end of week one. Not to evaluate them, just to ask: what was confusing, what did you need that you didn’t have, and is there anything blocking you? Then actually fix the things they flag, because the second thing that happens here is you’re improving your onboarding process for every future hire.
Do it again at the end of week two. After that you can move to a normal cadence.
I’ve started using a simple async check-in for this at studios where leads don’t have bandwidth for daily sync time. Something like a Slack standup bot (Geekbot works fine, runs about $2.50/user/month) with two custom questions added just for new developers during their first month: “What’s one thing that’s still confusing?” and “Is there anyone you haven’t met yet who you think you should?” The second question turns out to be weirdly useful. New people often don’t know who to ask for what, and they’ll tell you who they’re missing if you prompt them.
When It’s a Mid-Project Hire
Sources
Onboarding someone into an ongoing project is its own beast. The game has history. Design decisions were made, reversed, made again. There are systems nobody touches anymore. There’s a character controller that one person rewrote in 2024 and nobody fully understands. Context is everything, and you can’t document all of it.
What you can do is schedule one “context dump” meeting with each discipline lead, explicitly framed as “here’s the weird stuff you’ll encounter and why we did it that way.” Not a tour. Not a design review. Just a 30-minute conversation about the landmines. Engineers do this with engineers, artists with artists, designers with designers. It works better as same-discipline conversations because the nuance transfers more cleanly and people are less guarded.
Assign the new person a small, real task in their first week. Not a tutorial task. Something that actually ships. It doesn’t have to be big: a bug fix, a minor content pass, a tool tweak. Completing something real builds confidence and forces them to understand the pipeline in a way that reading docs never does. I learned this from watching a senior designer I really respected once assign a brand new hire to fix three specific UI strings on their first day. Tiny task. But it meant going through source control, building, checking in, and confirming in a live build. They knew the whole flow before the week was out.
Photo: Ketut Subiyanto via Pexels
