How to onboard a remote hire in a different time zone (first-week playbook)

When a hire shares your office, onboarding can be improvised. You point at a screen, grab someone for a quick intro, answer questions as they arise. Move that same person eight or ten zones away and improvisation collapses: every unplanned question now waits until tomorrow. The fix is not more meetings. It is deciding, ahead of time, what must happen live and what can happen alone.

Why does a distant hire need a different plan?

The hard constraint is the overlap: the slice of the working day you genuinely share. A colleague in London and one in San Francisco share only a couple of hours; London and Sydney may share almost none. Everything that depends on a reply, an introduction or a decision has to fit inside that window, or wait a full day. Treat the overlap as your scarcest resource and the rest of the plan follows.

So the goal of week one is simple: make the new hire productive and welcome without requiring you to be awake at the same time. That means most of the material is asynchronous by default, and the precious shared hours are reserved for the things that truly need a human on the other end. The stakes are high even for co-located teams: Gallup finds that only 12% of employees strongly agree their organisation does a great job of onboarding new hires, so a distant hire, with even less margin for improvisation, deserves a plan that is deliberate from the start.

What should you prepare before day one?

Do the unglamorous work in advance. A distant hire cannot lean over and ask, so the written record has to carry the load.

• A written first-week plan the hire can read on their own clock, listing what to do each day and roughly how long it takes.
• Recorded walkthroughs of the things you would otherwise demo live: the codebase tour, the deploy process, how the product actually works. A five-minute screen recording with narration beats a live session they have to stay up for.
• Access sorted in advance. Accounts, repositories, tools and calendars provisioned before they start, so day one is not lost waiting on an admin who is asleep.
• A short recorded welcome from their manager, so a friendly face exists from minute one even if the first live call is on day two.

How do you find the right hours to meet?

Before you schedule anything, look at their actual local time, not your assumption of it. Half-hour offsets and daylight saving quietly shift the overlap, and a call you think lands at 9:00 AM for them may land at 7:30 PM. The safest habit is to read each person's real clock rather than do the arithmetic in your head, which is exactly what Atlas shows you. Pick the one or two hours you reliably share and guard them.

The day-by-day first week

This is a template, not a rule. Compress it for a two-hour overlap, stretch it where overlap is near zero. The shape matters more than the exact hours.

Notice the pattern: every live block is something that genuinely needs two people present, and everything else is work the hire owns alone. The reflection on day five is not a formality; the questions a fresh hire asks are the cheapest audit you will ever get of where your documentation is thin.

Who should be their onboarding buddy?

Assign one existing teammate as the buddy: the person who answers the small questions a new hire is too unsure to raise formally. For a distant hire there is one non-negotiable rule. The buddy's working hours must overlap theirs. A buddy who is asleep whenever the new hire is stuck is no buddy at all; every question waits a full day and the week stalls.

If your team is spread thin, it is better to pick a buddy in a closer time zone than the most senior person available. Proximity in hours beats seniority here. If you are still mapping who overlaps with whom, our note on core collaboration hours is a good place to start.

How do you set expectations so nobody burns out?

Say the quiet part out loud on day one. A new hire who does not know the norms will assume the worst, watch chat at all hours, and feel guilty about a message they could not answer overnight. Remove that anxiety with a few plain statements:

1. Async is the default. A reply within one working day is normal, not slow. Most things do not need an immediate answer.
2. Name what is actually urgent. Identify the one or two channels that warrant a fast response and how to use them, so everything else can wait without worry.
3. Protect their hours. Make clear you do not expect them online outside their working day. If you are in a region with right-to-disconnect rules, say how that applies; if not, set the same expectation anyway.
4. Write decisions down. When something is decided in a call, post a short summary so the people who were asleep are not left guessing.

The principle behind all of it

Onboarding a distant hire well is mostly an act of sequencing: front-load everything that can be done alone, protect the overlap for the few things that cannot, and make the rules of the road explicit. Do that and someone ten zones away can finish their first week feeling oriented and welcome, not isolated. For the broader question of which hours a spread-out team should hold in common, see core collaboration hours.