What has to be ready before day one
Most onboarding problems are decided before the person arrives. The fix is a short checklist, completed the week before.
| Ready before they arrive | Why it matters |
|---|---|
| Accounts and access, tested | An hour lost to a missing login on day one sets the tone |
| Their first real task, chosen | Prevents the shapeless first fortnight |
| A named point of contact | Somebody to ask small questions without feeling awkward |
| A written note on the business and customer | Context they can re-read, not a monologue they half remember |
| Calendar invites for the week already sent | They can see the week has been thought about |
| Manager time blocked out on days one and five | Both ends of the week are the ones that matter |
The single best predictor
Whether access works on the first morning. It is unglamorous and it is the most reliable signal a new hire gets about how organised the team is. Test the logins yourself the day before, with their credentials, not yours.
The five days
Day one: context, not paperwork
Cover the business, the customer, and the problem your team exists to solve. What you sell, who buys it, what usually goes wrong. Then where their role fits into that.
Give them something written to keep. Nobody retains a two hour verbal briefing, and a document means they can re-read it in week three without asking a question they feel they should already know the answer to.
Manager-ledKeep admin to one hourDay two: people and how work moves
Short introductions with the people they will work with regularly. Fifteen minutes each, and tell them the purpose is to know who to ask about what, not to be impressive.
Then walk them through how a piece of work actually travels: where it starts, who touches it, where it is recorded, how it finishes. Most teams explain the tools and skip the flow, which is the part that is genuinely hard to work out alone.
3-4 introductions maximumShow the flow, not just the toolsDay three: a small, real task
Something genuine, with an actual outcome, scoped so that it can be completed in a day or two and so that getting it wrong costs nothing.
The point is not the output. It is that they experience your whole process end to end while somebody is still watching closely enough to catch confusion.
Real work, low stakesPair them for the first hourDay four: feedback, in both directions
Review the task with them. Be specific about what was right and what you would change, and say why. Vague early feedback is the reason people repeat mistakes for months.
Then ask what has been confusing, what took longer than expected, and what they expected to exist that does not. A new person can see the gaps in your process clearly for about three weeks, and then they cannot any more.
Ask before they normaliseWrite down what they tell youDay five: review the week, set the next 30 days
Half an hour. What they now understand, what is still unclear, and what specifically they will own over the next month.
End with something written: two or three objectives for 30 days, and what good looks like for each. Without this, week two starts with them waiting to be told what to do, which is the most common way a strong first week is wasted.
Written 30-day plan30 minutes, manager-led
Choosing the first real task
The first task carries more weight than its size suggests. Good ones share four properties.
It is real, meaning the output is actually used rather than thrown away. It is small enough to finish inside two days. It touches the normal process, so they learn how work moves rather than a special case. And failure is cheap, so nobody has to hover.
Things that make bad first tasks: reading the entire documentation set, a task blocked on someone else's availability, a task nobody has done before, and anything where the correct answer is unclear even to you.
Onboarding someone remote
The structure above holds. What changes is that nothing incidental happens by itself.
Everything gets written down, because there is no desk to lean over. Introductions have to be booked, because they will not occur naturally. The point of contact matters more, since there is no visible cue that someone is stuck. And it is worth explicitly telling a remote starter that interrupting people is fine, because otherwise they will sit blocked for half a day rather than send a message they think might be an imposition.
One further thing: say out loud what your working-hours norms actually are. A remote starter who sees evening messages will conclude that evening work is expected, and nobody will ever correct them.
The 30-day checkpoint
This is the step most small teams skip, and it is where a bad hiring decision either gets fixed or gets expensive.
Thirty minutes at day 30. Three questions: are the objectives from day five on track, what is still slower than it should be, and what does the person need that they have not asked for. Then repeat at 60 and 90 days.
The value is not evaluation. It is that a problem visible at day 30 is nearly always solvable, and the same problem at day 90 has usually hardened into a view about the person rather than about the situation.
Frequently asked questions
- How long should onboarding take?
- The structured part is the first week, with checkpoints at 30, 60, and 90 days. Full productivity takes considerably longer in most roles, and pretending otherwise is what leads teams to stop supporting someone at the point they most need it, around week three.
- What should a new hire actually do on day one?
- Understand context and meet people. Give them the business, the customer, and how their role connects to both. Avoid filling day one with policy documents and tool setup, which they will not retain and which teach them that the job is admin.
- Should a new hire ship something in week one?
- Something small and real, yes. A genuine contribution that reaches a customer or a teammate does more for confidence and for learning your process than two weeks of reading. Scope it so that failing is cheap.
- Who should own onboarding in a small team?
- The hiring manager owns it, with one other person acting as the day-to-day point of contact for small questions. Splitting it across everybody means nobody notices when the new person is stuck, which is the failure mode in teams under twenty.
- How is onboarding different for a remote hire?
- Everything incidental has to be scheduled. In an office a new person absorbs norms by being present. Remotely they absorb nothing unless it is written down or explicitly arranged, so the written context and the deliberate introductions carry the entire load.