Onboarding an offshore engineer in the first ten days

A new engineer in your office who is blocked on access gets up, walks over to someone and is unblocked in ten minutes. A new engineer twelve hours away, three days in, with no history with anyone on the team, sends a polite message into a channel and waits. By the time you notice, the first fortnight has gone — and the thing they have learned about working here is that being stuck is normal.

Almost everything that goes wrong in the first ten days is a version of that. The fixes are unglamorous.

Before day one

All of this is someone's job in the week before the start date, and all of it is finished before the start date.

• Every account created and logged into once by the person who created it. Not requested — tested. Repository access, cloud console, CI, the error tracker, the ticket system, the design tool, the VPN if there is one.
• Hardware delivered and confirmed working, with whatever device enrolment your security policy requires already done.
• A written first-week plan in a document the engineer can read before they start.
• A calendar that already contains their recurring commitments, in their time zone, with the overlap window marked.
• One small, real, already-triaged piece of work waiting with their name on it.

The single most common failure is raising access requests on the morning of day one. In most organisations that is a three-to-five working day queue, and it consumes the entire first week of a hire you waited nine days for a shortlist to find.

Days one to three: context, not setup

If the list above is done, the first three days are free for the thing that actually matters: why the system is the way it is.

Give them a buddy — one named person, in the same shift, with answering questions written into their objectives for two weeks. Not a mentor, not a manager. Someone whose job is to be interruptible.

Spend the shared hours on the history that is not written down anywhere. Why the service was split. Which part everyone is afraid of. What was tried in 2023 and abandoned, and why. A new hire can read your architecture documentation alone; they cannot reconstruct the reasoning that produced it, and without that they will spend their first quarter either repeating decided arguments or being too cautious to make any.

Keep stand-up short and do the rest in writing, so that what is said on day two is still readable on day thirty.

Days four to ten: a change in production

The target is one small, real change, shipped to production, by the end of the second week.

Small is the point. It is not a measure of productivity — it is a test of the pipeline, and of every assumption in the paragraphs above.

For scale: DX, measuring 400 organisations with more than five hundred developers each, puts the average time to a new engineer's tenth merged pull request at 33 days. One change in ten working days is not an aggressive target against that; it is roughly the first step of a normal ramp, pulled forward deliberately so that the problems surface while they are still cheap. DX is careful to say the metric counts changes rather than understanding, and that caveat matters here too — shipping on day nine proves the pipeline works, not that the engineer knows your system. Running the suite locally finds the environment problem nobody documented. Opening a pull request finds the review convention that only exists in people's heads. Deploying finds the permission that was never actually granted, as opposed to requested. Each of those is cheap to find in week one on a change that does not matter, and expensive to find in week six on one that does.

Ship it in the overlap window with the buddy watching, so that when something goes sideways there is somebody there.

Ask the blocked question out loud

The last piece is behavioural, and it is the one that does not appear on anyone's checklist.

A new remote hire, especially one newly joining a team in another country, will wait noticeably longer before saying they are stuck. Nobody wants their first signal to the team to be a problem. So the signal does not come, and the first you know is a quiet week.

This is the part the research is clearest on. When Microsoft surveyed 267 engineers who had onboarded entirely remotely, the hardest thing they reported was not tooling or documentation — it was building a social connection with the team. Asking for help is a social act before it is a technical one, and a new hire who has not yet built that connection has nothing to spend on it.

Ask explicitly and daily for the first two weeks — "what are you blocked on, and who do you need?" — and then unblock it visibly, in a channel, where everybody can see that raising it was the right thing to do. Two weeks of that is usually enough to establish it, and establishing it is worth more to a distributed team than any document in the onboarding folder.