Onboarding External Developers Without Losing a Sprint
The contract is signed on a Thursday and the developer starts Monday. By Friday they’ve tried to build the project twice, failed both times, and asked four questions that each took a day to answer because the only person who knew was in a different timezone.
Sprint one is gone. Nobody planned for that, and almost everybody has lived it. The uncomfortable arithmetic is that most of the cost in an external engagement isn’t the rate — it’s the two to four weeks before that person produces something you’d actually ship.
The first sprint decides the engagement
Ramp time is measurable and mostly ignored. SHRM’s 2025 data puts new hires at roughly 25 percent productivity in their first 30 days without structured onboarding. On a senior engineer’s rate, that gap is real money, and it repeats every time you add someone.
Games make the problem worse than general software. A Unity or Unreal project isn’t a codebase. It’s a codebase plus editor state, plus a content pipeline, plus a build farm, plus a set of conventions that live in three people’s heads and nowhere in the repository. A new engineer can read every line of C++ in the project and still not know why the level loads differently on the build machine.
The teams that handle this well aren’t more organized in general. They’ve just decided that ramp is a deliverable with an owner, the same way a feature is.
Pre-boarding beats orientation
Almost everything expensive about week one can be moved into the week before, and almost nobody does it. Access requests sit in a queue. Hardware ships late. The repository invitation goes to the wrong email. None of these are hard problems, and collectively they eat three days.
Get the accounts provisioned before the start date: source control, issue tracker, build system, engine license, internal chat, and whatever asset management tool the art team uses. If your project needs a Perforce workspace with a specific stream layout, write it down and send it in advance rather than explaining it on a call.
Then verify the build yourself. Take the onboarding document, follow it exactly on a clean machine, and time it. Most teams discover their setup instructions have been quietly wrong for eight months, because everyone currently on the project set up their environment before the change that broke them.
The practical version of this is a planning decision, not a technical one. Before you hire video game developer support for a milestone, name the person spending four hours preparing the environment and put them in the schedule. If the answer is “they’ll figure it out,” you’ve converted four hours of senior time into two weeks of expensive confusion.
The first ticket should be real
There’s a reflex to give new people something harmless. Fix a typo, update a README, tidy some warnings. The intent is kind and the effect is that you learn nothing about whether your pipeline works for them.
Give them a small but genuine ticket in the first few days — a real bug, in a real system, that goes through the real review and build process. It surfaces every broken step at once: the permission they don’t have, the tool that needs a license, the review process nobody documented, the test suite that only passes on Windows. Better to find all of that on a low-stakes bug than three weeks later on something that matters.
One thing to resist: pairing them with your busiest senior engineer. The person who knows the most is usually the person with the least time, and a mentor who’s always in another meeting is worse than a mid-level engineer with actual availability. Availability beats expertise in week one, every time.
It also helps to be explicit about what the first ticket is testing. Tell them the goal is to exercise the pipeline end to end, not to impress anyone. That removes the pressure to quietly work around a broken step rather than reporting it, which is the single most common way onboarding problems survive for a year.
Engine context is the part teams skip
Language fluency and engine fluency are not the same thing, and job descriptions blur them constantly. GDC’s 2026 State of the Game Industry found Unity is the primary engine for 30 percent of developers and Unreal for 42 percent — but knowing an engine in general tells you very little about knowing a specific project built in it.
This is where most of the hidden ramp cost lives. Teams that hire unity developers tend to assume C# fluency transfers directly, and it does. What doesn’t transfer is the project’s particular relationship with Addressables, its assembly definition layout, its render pipeline choice, whatever custom editor tooling got built in year one, and the three systems that look wrong but exist because of a platform certification requirement from two years ago.
A one-page architecture note covering those decisions — what’s custom, what’s standard, and what looks broken on purpose — saves more time than any other document you could write. It takes an afternoon. Most projects have never had one written.
The Cost Was Never the Rate
Return to the developer who lost a week trying to build the project. Nothing in that week was their fault, and nothing in it was unpredictable either — it was the accumulated cost of instructions nobody had tested and context nobody had written down.
The reframe worth holding onto is this: ramp time is not something that happens to a team, it’s something a team produces. A project that takes four weeks to onboard someone will take four weeks to onboard the next person too, and the one after that, until somebody treats it as work with an owner and a due date. Rates are negotiated once. Ramp gets paid every single time.
Also Read: brandrank.ai normalization transformation rules
Frequently Asked Questions
How long should onboarding take on a live game project?
Target a working build on day one, a merged first ticket inside the first week, and independent work by week three. On a large codebase with heavy custom tooling, four to six weeks is realistic. If it’s consistently taking longer than that, the bottleneck is usually undocumented setup rather than the people you’re bringing in.
What should be in an onboarding document for external engineers?
Environment setup verified on a clean machine, engine and toolchain versions with exact patch numbers, source control layout and branching rules, build and deploy steps, a one-page architecture note covering custom systems, coding conventions, and who to ask about what. Keep it in the repository so it gets updated with the code rather than rotting in a wiki.
Should external developers attend internal standups and planning?
Yes for standups and sprint planning, since both carry context that’s hard to transmit any other way. Retrospectives are a judgment call — some teams need the room to be internal to be honest. Whatever you decide, be explicit about it up front rather than leaving people to guess whether an invitation was an oversight.
How do you measure whether onboarding is working?
Track two numbers: days to first merged pull request, and days to first ticket completed without help. Both are easy to pull from your existing tools and both trend in the right direction when onboarding improves. Sprint velocity is too noisy to tell you anything useful in the first month.
