The journey of a thousand miles begins with a single step. When I ramp a new hire up, I like to take a three-pronged approach to help them learn stuff through a variety of exposures. Depending on the new hire’s experience level and their performance on the initial tasks, this approach allows the new hire to engage as much as they feel comfortable, as well as provide some pretty good context to me for what to do next with them.

ALT

The first prong is assigning the new hire fairly easy tasks in the area they’ve been assigned to work on. This typically starts with fixing existing (and fairly simple) bugs. Small bugs are a good way to familiarize a new hire with the code, assets, tools, and work flow. In addition, it also provides good acceptance criteria for completing the task. There are also almost always small bugs available for fixing on large projects, especially long-running large projects.

ALT

Second, I put new hires into circulation for reviewing other peoples’ work (e.g. code review, design review, art review, etc.), especially those working in the same area as the new hire. They help look over work done by others and get an opportunity to ask questions about the work being done. This helps show the new hire how others on the team are doing their work and gives them an avenue to ask questions about how things work.

ALT

Third, I like pairing the new hire up with a mentor so they can feel more comfortable asking general questions without feeling nervous or fearing judgement. More experienced new hires probably won’t need a mentor as long, but it is good to have someone who can answer questions and suggest helpful information to the new hire. One big problem that many new hires have is the unknown unknowns - things that they don’t know that they don’t know. The mentor should help point those things out.

ALT

As the new hire gains experience with the project and levels up, we can repeat this process for each new area of responsibility that we want them to work on. I might start a new hire with class design first, before expanding their responsibilities to enemy or encounter design. With luck, they’ll be able to pick things up more quickly as they become more familiar with the project and the way things work. The first few weeks of being a new hire on a big project is often like drinking from the firehose - it’s information overload on all sides. I’ve found that assigning small actionable tasks, peer review participation, and providing a mentor are all very useful means of structuring the onboarding process and make it a little less daunting.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ