Onboarding a remote employee — the first thirty days

A new hire in an office learns the company by accident: from the tone of a call they pick up which job is urgent and which is only flagged urgent. Nobody planned that and nobody wrote it down.

Remotely that channel disappears, leaving whatever someone deliberately recorded: usually logins, the handbook and a list of mandatory training.

In the companies we talk to, remote onboarding rarely breaks on access. It breaks two weeks later: the new person knows where to click but not why, and the question sounds too basic to post in a team channel.

Unwritten knowledge decides whether someone settles in#

The formal part is easy — you can see when it is done. The hard part is the one nobody runs.

Who actually decides what. The org chart says one thing, practice another.

Which rules are hard and which are habit. Some procedures matter step by step, others survive because nobody removed them, and a newcomer cannot tell which is which.

What good work looks like here. Not correct, but at the standard this company expects — which travels by example, and remotely there is none.

What is not done. Things somebody tried that went badly; without that history the new person walks the same road.

None of it travels on its own: write it down, or schedule the conversation where it gets said.

What to prepare before day one#

With no colleague at the next desk, an obstacle costs an hour of waiting.

Access that works at nine. All of it, not "the rest this week".

A short reading list. A few items in order, each with a sentence on why to read it.

The buddy's name and the first call already in the calendar. Not "give me a shout if you need anything".

A first-week task, chosen in advance. On Monday nobody has the headspace for it.

A note to the team. Who is joining, what they will do, what to ask them about. Nobody walks past a remote desk.

Week one: one task finished on their own#

A typical remote first week is introductory calls and reading. Five days on, the new person knows a fair amount, has produced nothing, and nobody knows whether this will work.

Better: one real task, finished independently by Friday. A good one has four properties:

• It is real. It goes into the system or to a customer, not into the bin.
• It is small. Two or three days for someone who knows how — a week for someone learning.
• It touches several places the person will work in day to day.
• It costs nothing if it fails. The new hire is entitled to make a mess of it.

A task generates questions; documentation does not, because you cannot yet tell what you fail to understand. Finishing something end to end exposes every gap within an hour.

The buddy: one person, a narrow remit#

A buddy is not a mentor for everything, nor the manager.

Who. Someone doing similar work who was new recently enough to remember what was unclear.

Remit. Questions of the "how is this done here" kind — not technical training, not assigning work, not assessment.

Format. Fifteen minutes a day in week one at a fixed time, initiated by the buddy; every other day after that. A conversation scheduled for "whenever you need it" never happens.

The boundary. The buddy does not write a review of the new hire. If they do, the new hire stops asking the questions that expose them — the ones the role exists for.

One person, not a team: "ask anyone" remotely means "ask nobody".

Checkpoints: day 7, 14 and 30#

Three conversations, each about something different, booked on day one.

Day 7 — can they work at all. Equipment, access, whether the task has started. Best question: what stopped you for more than fifteen minutes this week.

Day 14 — do they understand the context. Ask them to explain what a process they took part in is for. The gaps show up immediately, and they are usually the company's. Then: what turned out different from what recruitment suggested.

Day 30 — are they working independently. Which tasks they do without asking, which still need someone beside them, what is missing to change that. Also the conversation the other way: is the job what they came for.

A new hire's questions are a ready-made documentation plan#

The first month is the only window in which anyone sees every place a description is missing; a month later they stop seeing them.

The answer goes where the next person will look. Reply in a direct message so nobody sits blocked, then paste it into the shared place. An answer given only in private helps once.

The new hire writes the note, the buddy corrects it. Someone who understood a thing yesterday explains it better than someone who has known it for years.

Three notes a week, not the full set at once. A dozen short notes from one onboarding beats what the company had.

The same question from three people is a process fault, not a missing document. Before describing a step, check whether it can be removed.

A model answering questions from company data shortens this but does not replace it — it does not know what nobody wrote down. Better: an agent drafts the note from what is in the system, a person approves it before publication. An error in onboarding material propagates to every hire after it.

Summary#

Remote onboarding breaks not on hardware or access but on the knowledge that in an office travels by itself. Three things make up for it: preparation before day one, one real task finished in week one, and conversations at days 7, 14 and 30 — plus one person responsible for questions and a habit of recording the answers.

Thirty days is not there to make the new hire know everything, but to make them know what they do not know — and where to check.

The wider context — how to arrange the tools so that this knowledge does not scatter across six apps — is in the guide on remote work tools.