The short version
- A new hire's day one problem is not the material. It is that every question stops them, and the person who knows is asleep.
- Separate the questions that can wait a night from the ones that cannot. Handle the second group with access and defaults, not with a meeting.
- Front load the overlap. Spend it in week one and taper, rather than spreading a thin daily call over a month.
- A new joiner asks far more questions than anyone else on the team. Design the first month around that rather than treating it as a nuisance.
Onboarding someone in a distant time zone is where a team discovers how much of its knowledge lives in conversation. The documents are fine. The problem is that a new person hits an unfamiliar thing every twenty minutes, and each one needs a human who is nine hours away.
"I spent my second day reading, because I had four questions by 10:00 and nobody to ask until the evening."
What day one actually looks like
A new joiner in Manila starting with a team in Berlin. Berlin comes online in the Manila late afternoon. So the new hire's first six working hours have no colleague available at all.
In an office, those six hours would contain twenty small questions, each answered in thirty seconds. Remotely and across a gap, each becomes a decision: ask and wait, guess, or stop. New joiners almost always choose to stop, because guessing feels risky in the first week, and stopping looks like reading.
The result is someone who appears to be settling in quietly and is in fact stuck, and who will not say so for a fortnight.
Two kinds of question
Split them, because they need different answers.
| Kind | Example | Fix |
|---|---|---|
| Can wait a night | "Why did we choose this framework?" | A written queue, answered in the overlap |
| Stops them now | "I do not have access to the repo." | Prevent it. Access before day one, always. |
| Stops them now | "Should I use A or B here?" | A written default. "When unsure, do A and flag it." |
The written default is the most underused tool in distributed onboarding. A new joiner with permission to proceed on a stated default keeps working, and the flag means nothing goes unnoticed. Without it, every fork is a full stop.
Front load the overlap
Most onboarding plans spread contact thinly: a thirty minute call every day for four weeks. That is exactly the wrong shape, because question volume is heavily concentrated at the start.
Front load it instead. Week one gets three hours of live time a day, even where that means someone shifts their hours for five days. Week two drops to one hour. Week three to two calls. Week four to the normal rhythm. The total is similar and the value is far higher.
If anyone is going to shift hours for a week, it should be the existing team member rather than the new hire, who is already absorbing a great deal. See the first 30 days of remote onboarding.
A first month that fits the gap
- Week one: one small thing, finished. Not reading. A real change, shipped, however small. It surfaces every access and setup gap in two days rather than two weeks.
- A running question list. The new hire keeps one visible list. They add as they go, someone answers in the overlap, and it doubles as your onboarding gap report.
- A named answerer per topic. Not one buddy. Three names, each for a different area, so a single person's holiday does not stop the onboarding.
- A weekly written check in from them. What is still confusing. Asked in writing, because people admit confusion more readily in writing than on a call.
The running question list is the highest value artifact here, and most teams delete it at the end of the month. Keep it. It is the most accurate list of your onboarding gaps you will ever have, and the next hire's plan should be built from it. See the new hire with forty questions and one person to ask.
What to do about the buddy
The buddy model assumes availability. Across a nine hour gap there is no availability, so the buddy becomes a person the new hire writes to and hears from the next day, which is not a buddy.
Two changes help. Name three people rather than one, so questions spread and no single person absorbs an onboarding on top of their job. And give the new hire a way to get the already known answers without a person at all.
That second part is what StandIn is built for. Each person on the team writes a short daily brief, about ninety seconds, mostly drafted from the work that already happened: what moved, what is open, what is blocked, what is next. A new joiner can ask where something stands, or what was agreed with a client, and get an answer from that brief in the owner's words, with a source under it. It never guesses, and when the answer is not in the record it says so and names who to ask, which is exactly what a new person needs to hear rather than a confident invention. The six hours before Berlin wakes up stop being dead time. See the first 30 days.
Common Questions
How long does remote onboarding across zones take?
Expect the ramp to be longer than a co located hire and plan for it openly, rather than letting the new person conclude they are slow. Saying so in week one removes a lot of private anxiety.
Should the new hire shift their hours at the start?
For a few days of week one, by agreement, yes. As a standing expectation, no. It is the fastest way to lose a hire in month four, and they will not tell you that is why.
Is recorded video onboarding worth making?
For things that are stable and visual, yes. For anything that changes quarterly, no, because it will be wrong and nobody will notice. Video also cannot be searched at the moment of a specific question.
How do we know whether onboarding is working?
Watch the question list. Questions that keep repeating across successive hires are a documentation gap. Questions that stop entirely in week two usually mean the person gave up asking, which is worth a conversation.
Log off like you mean it.
Your StandIn answers the questions that come up while you're out, from what you actually wrote down, so the return pile stays small.