How to Onboard a Remote Hire

A new engineer joined a team I advised, based in Manila, while the rest of the team sat in London and Toronto. Smart hire. Strong interview. Her first week, she got a laptop, a stack of Notion docs, and three "welcome aboard!" messages in a channel that then went quiet for her whole afternoon because everyone else had logged off.

By week three, her manager noticed she'd opened exactly one pull request. Tiny one. He assumed she was ramping slowly and gave it time. By week six, she'd mostly stopped asking questions in the channel. She wasn't struggling with the code. She was struggling with not knowing who to ask, when they'd be awake, or whether her questions were too basic to post in front of everyone. She quit at four months and told an exit interviewer she'd never felt like she was actually on the team.

Nobody did anything cruel. They just onboarded her the way you'd onboard someone three desks away, and she wasn't three desks away. She was nine timezones and a wall of silence from the nearest person who could help.

An office onboards people for free

Walk a new hire into an office and a hundred things happen without anyone planning them. They overhear how people talk to each other. Someone grabs them for coffee. They watch a senior engineer debug something on a shared screen and absorb half the team's conventions by osmosis. When they're stuck, they swivel their chair and ask the person next to them, and the answer comes in ten seconds.

A distributed team gives you none of that. The overhearing is gone, because the conversations are written and scattered across channels the new person doesn't know to read yet. The swivel-and-ask is gone, replaced by posting into a channel and waiting, sometimes half a day, for someone in the right timezone to wake up and notice. The casual osmosis that taught office hires the unwritten rules just doesn't happen.

So you have to build, on purpose, the things an office hands out for free. That's the whole job. Onboarding a remote hire isn't a lighter version of in-person onboarding. It's a different task, because the ambient support a new person leans on for their first month has been deleted, and you're the one who has to put it back.

Do the boring setup before day one

The fastest way to waste a remote hire's first week is to make them spend it waiting. Waiting on a laptop to ship. Waiting on a GitHub invite from an admin who's asleep. Waiting on access to the one repo they need, which requires approval from a manager in a timezone that overlaps with theirs for two hours a day.

In an office, blocked access is mildly annoying; you walk over to IT. Remote, a missing permission can eat two full days, because every back-and-forth to fix it costs a sleep cycle. The new person sits there, motivated and idle, forming their first impression of how the company runs.

Front-load all of it. Hardware ordered to arrive before the start date. Every account, repo, and tool provisioned the Friday before, not requested the Monday of. A checklist someone actually owns and runs, so nothing waits on a synchronous approval the new hire can't trigger themselves. None of this is hard. It just has to be done early, by a named person, instead of improvised in real time across a timezone gap that turns every small gap into a half-day delay.

Give them one person, with real overlap

The one move that helps most is to assign a single named human as the new hire's go-to. Not "the team." A person. The same mistake that sinks cross-timezone handoffs, where work owned by everyone is owned by no one, sinks onboarding too. When a new person's questions are addressed to a whole channel, they feel like they're bothering everyone and belonging to nobody.

Pick a buddy who shares at least two or three real hours of overlap with the new hire. This matters more than seniority. A mid-level engineer whose afternoon is the new person's morning is worth more in week one than a staff engineer twelve hours offset who can only answer overnight. The buddy's job is to be the safe, dumb-question destination, the person you DM instead of agonizing over whether something deserves a public post.

Then make the overlap a standing appointment. A 25-minute call every day for the first week, same time, in the window you both share. Not to status-check. To give the new hire a guaranteed moment where a real person will answer anything, so the questions they've been hoarding have somewhere to go before they curdle into the silent drift that took down the engineer in Manila.

Ship something real in the first week

Here's where most remote onboarding goes wrong: it buries the new hire in reading. A 40-page handbook, twelve recorded videos, a Notion garden of docs, and an unspoken expectation that they'll emerge fully briefed before touching anything.

Reading is passive, and passive is poison for a remote hire, because passive looks identical to drifting. Nobody can tell whether someone quietly reading docs at home is absorbing the architecture or quietly panicking. Give them a real task instead, fast. A small, shippable, genuinely useful piece of work in the first few days. Fix a real bug. Ship a copy change. Add a test. Something that ends in a merged pull request with their name on it before the end of week one.

A first PR does three things a doc never will. It forces them through your actual tooling and review process, which teaches more than any wiki page about how the team works. It gives them an early, concrete win, which is worth a lot to someone privately wondering if they made a mistake taking the job. And it gives you a real signal about how they work, instead of the absence of signal that a week of "reading up" produces. Pick the task before they start, scope it small, and make sure their buddy can unblock them inside their shared hours.

Write the culture down, because you can't repeat it live

On a colocated team, the unwritten rules transmit by exposure. Remote, if it isn't written, the new hire never learns it, because there's no hallway where it leaks out.

So write down the things that actually trip people up. When are people expected to respond, and when are they genuinely offline? Which decisions go in a channel versus a DM? What does a good update look like? This is the same muscle behind async-first communication, and a new hire is the best possible audience for it, because they'll feel every gap in the document the moment they hit it. A short, honest onboarding doc that explains how your team really operates beats a polished handbook describing a company that doesn't exist.

Point them at the norms early. The Slack habits a distributed team runs on, how times get written so nobody guesses whose 3pm it is, where the real conversations live. These feel obvious to you because you absorbed them slowly. To a new hire dropped into the middle, they're invisible until someone spells them out.

Watch for the quiet one

The most dangerous failure mode in remote onboarding is the new hire who goes silent and looks fine. No complaints, no dropped deadlines, just a slow fade in how often they show up in channels, ask questions, or volunteer an opinion.

In an office you'd catch it in a day; you'd see them looking lost. Remote, a struggling new hire and a thriving one can produce the identical Slack footprint, which is to say almost none. The engineer in Manila didn't send up a flare. She just got quieter, and quiet read as fine until it read as gone.

So treat the first month as the period where you over-invest in contact, then taper. Once someone's settled, give them the long uninterrupted stretches that make distributed work worth doing. But early, lean in. A new hire's silence is rarely a sign that everything's fine. It's usually a sign they've decided their questions aren't worth the cost of asking across a timezone gap, and that decision, left alone, is the first step out the door.

The first two weeks set the pattern for everything after. Get them right and you've got a teammate. Get them wrong and you've got someone politely waiting until it's reasonable to leave.

Onboard Without the Timezone Math

A new hire's first weeks are confusing enough without parsing whose 2pm is whose. Timely converts every time mention in Slack to each reader's own timezone automatically, so when their buddy says "let's sync at 2pm GMT," the new person in Manila sees their own local time and shows up on time without doing the arithmetic.

Add Timely to Slack — Free · See how it works