Most onboarding checklists are written for the wrong reader. They are built by HR, stored in an HR folder, and worked through by HR, while the person they describe never sees a line of it. The new hire experiences onboarding as a series of surprises: a laptop that arrives on day three, a system nobody mentioned until they needed it, a manager who assumed someone else had explained the probation criteria.
The list below is written the other way round. Every item names an owner, because the item that fails is almost never the item nobody thought of. It is the item everybody assumed belonged to someone else.
The whole thing is written out below as well, section by section, with why each line is on the list. If you only want the file, take it and go.
Onboarding is often used to mean the first morning. That is orientation, and it is one item inside a process that runs for about three months.
The process has four stages, and they are not equal in weight. Before day one is preparation, and it decides most of the outcome. Day one is introduction. The first week is orientation in the real sense, learning where things are and who does what. Then ninety days of integration, which is where the person moves from being shown work to owning it.
Where it ends is worth stating, because a process without an end never gets reviewed. It ends at the ninety-day mark, with two events on the same day: a review against what the manager wrote before the person started, and a question about what onboarding missed. If your process has no end, what you have is a first week and then silence.
The other boundary worth drawing is between onboarding and training. Training teaches the job. Onboarding makes it possible to do the job here: the access, the people, the norms, the first task, and knowing what good looks like in ninety days. A new hire who has been trained but not onboarded knows the work and cannot get anything done.
Every company that has hired twice has a checklist. Ask to see it and you get a spreadsheet with forty rows and no dates, or a wiki page last edited by somebody who left.
The list is easy. Three things make it work or not.
The first is ownership. A row that says "set up accounts" with no name beside it is a row that gets done on day two, by whoever notices. Split it: IT creates the accounts, the manager says which ones, HR confirms the start date they key off.
The second is timing. Half of a good onboarding happens before the person arrives. If your list starts on day one, day one becomes paperwork day, and the new hire spends their first eight hours reading policies instead of meeting the people they will work with.
The third is that the list has to reach the new hire. Not the HR copy with the internal notes, the version that says what happens to them and when. Most of the anxiety in a first week is not about the work. It is about not knowing what is supposed to happen next.
This is the half that decides the rest, and the half most often compressed into the morning of the start date.
HR owns:
The manager owns:
IT owns:
That fourth IT line sounds pedantic until the first morning, when a new hire cannot enrol their second factor because the enrolment link goes to the mailbox the second factor is protecting.
The goal for the first day is not coverage. It is that the person leaves it having met people, having done one real thing, and knowing what tomorrow looks like.
What counts as that one thing depends entirely on the job, and this is where onboarding advice usually shows its engineering bias. For a developer it is a merged pull request or a closed ticket. For support, one ticket answered with somebody watching. For a salesperson, sitting in on a live call and writing the follow-up note. For a lawyer or a finance hire, one clause or one line item reviewed on something real rather than a training file. The test is not whether it shipped to production. It is whether they went home having contributed something instead of having been shown things.
What does not belong on day one: eight policy documents, the full compliance suite, and a stack of systems training for tools they will not touch for a month.
That last line is the only mechanism most companies have for improving onboarding at all, and it costs ten minutes.
At thirty days:
At sixty days:
At ninety days:
The ninety-day answer is the only feedback loop in this document, and it needs one named owner and one review a quarter. Without that, the answer is interesting, it goes into a document nobody opens, and within a year the checklist describes tools that were replaced and people who left.
The plan is usually written as three headings with aspirations under them, which makes it unusable at the review, because nothing in it can be true or false.
Write each line so that at the end of the period there is a yes or a no.
At thirty days, learning. "Can explain what the team owns and who asks for what, and has shipped one small change end to end." Not "understands the product".
At sixty days, contributing. "Owns the weekly report, and has made one decision in it that was not escalated." Not "is becoming more independent".
At ninety days, owning. "Runs their own queue, and the manager finds out about routine decisions afterwards rather than before." Not "is fully ramped up".
Two rules keep it honest. Write it before the person starts, not during their first week, because a plan written after they arrive is shaped around what they turned out to be good at. And keep it to one paragraph per stage, because the version that survives to the review is always the short one.
Someone moving between teams gets nothing, on the grounds that they already work here. They know the building, the payroll and the coffee. Everything else is new, and nobody is checking.
The short list for an internal move: access to the new team's systems granted and, harder, access to the old team's systems reviewed and removed on a date. A first task in the new role. A buddy in the new team, because their old network answers the wrong questions. The ninety-day statement, same as any hire. And an explicit conversation about what they are no longer responsible for, which is the item that gets skipped and is the reason internal movers spend their first two months doing both jobs.
The single most common failure in onboarding is not a missing task. It is a task with two plausible owners and no named one.
| Area | Owner | Fails as |
|---|---|---|
| Contract, payroll, benefits | HR | Person works a month unpaid on the wrong tax code |
| Start date communicated to IT | HR | Accounts created on day two |
| Which access this role needs | Manager | IT copies the last person and grants too much |
| Accounts, hardware, second factor | IT | Day one is spent waiting |
| The first task | Manager | Week one has no work in it |
| The ninety-day statement | Manager | Probation review has nothing to measure against |
| Buddy assignment | Manager | Buddy finds out by being asked a question |
| Compliance training | HR | Crammed, resented, forgotten |
| Rewriting this list | Whoever asked the ninety-day question | Never happens |
If you take one thing from this page, take the right-hand column. Those are the failures we see repeatedly, and none of them are caused by not knowing what to do.
Remote onboarding is not the same list delivered over video. Four things change.
Hardware has to arrive before the start date, which means ordering it when the offer is signed, not when the contract comes back. Build in a day of slack, and have someone confirm it arrived and switches on.
The time zone goes in writing, on the calendar, in the team channel. Not "she is in Europe" but the actual working hours, so nobody schedules the first-week introductions at seven in the evening for one side.
Written-first norms have to be explained, because they are invisible. Where decisions get recorded, what gets a document and what gets a message, which channel is read within the hour and which is read weekly. In an office, a new person learns this by watching. Remote, they learn it by getting it wrong.
And the first meeting is a call with cameras, not a chat message. The whole point of day one is that the person meets people, and a remote start makes that the thing most easily skipped.
Four numbers are enough, and three of them are free.
Time to first shipped work. Count the days from the start date to the first thing that reached a real user, a real customer, or a real colleague who was not onboarding them. If it is measured in weeks, day one is doing paperwork.
Access tickets raised in the first fortnight. This is a proxy for how wrong the role template is, and it is the cheapest signal in the list. Every ticket is a line somebody should have added to the IT checklist and did not.
Ninety-day retention, and its uncomfortable sibling, ninety-day regret. The second one you only get by asking, and only if the person believes the answer is safe.
And the answer to the confusion question, asked in week one and again at ninety days. Not a score. The actual sentences. They are the raw material for next quarter's version of this checklist.
The checklist as a PDF, A4, laid out to be printed or filled in on screen. Everything above, plus a blank ninety-day statement and one worked example: a first engineering hire at a company of eleven people, starting remote on a Monday, with the real dates left in.
No form, no email address, nothing to sign up for. Copy it, rename it, put your own logo on it and use it inside your company.
It is generated from this page, so the two cannot drift apart. When a line is corrected here, the file is rebuilt from the same source.
Nothing above is a format problem. Onboarding fails on ownership, on timing, and on nobody rewriting the list, and no video fixes any of those. Get those wrong and a beautifully produced welcome film changes nothing.
But there is one line in this document that is a format problem, and it is the third of the three things at the top: the list has to reach the new hire. This document is built for the people running the process. The person on their first morning, who has just been handed a laptop and three logins and eleven names, is not going to read a dozen pages of it, and nobody should expect them to. What they need is the shape of the four stages, who to talk to, and what happens next.
That is the narrow thing we build for: taking a document somebody already wrote and turning it into something the other audience will actually watch. The method, including the places our engine got it wrong and the wording that fixed them, is written out in how to turn a document into a video.
If you want to try it on your own onboarding document, the honest test is to paste in the one you already have rather than writing a clean one for the occasion. That is the case that tells you whether it works.