TL;DR
- The core decision: whether you're designing a first day or designing the period that determines whether somebody becomes useful.
- When doing nothing is right: when new people are productive on the timeline you expected and nobody has been left waiting for access, information or work.
- What has to be true: somebody can say what a new starter should be able to do without help at the end of their first months.
- How the options split: by who carries the structure, which determines whether it survives a busy week.
- Decision rule: work backwards from what they need to be able to do, then ask what has to happen in what order. Designing forwards from day one produces an agenda, not a process.
- Outcome to expect: a shorter first day, more deliberate weeks two through eight, and fewer people quietly stuck at week six.
The Day That Gets All the Attention
A new person starts. There's an agenda for the morning, a folder of documents, a laptop that mostly works, and lunch with the team. Somebody has clearly put effort into it, and the day goes reasonably well.
Then Tuesday arrives, and there's nothing. The manager is in meetings. The person who was going to show them the system is off. They have access to some things and not others, a vague sense of what they're meant to be working on, and nobody obviously available to ask. So they read documentation that's two years out of date, send a few careful messages, and try to look occupied.
That pattern continues for a fortnight, quietly. Nobody notices, because nothing is visibly wrong: the new person doesn't complain, the manager assumes they're settling in, and the first real signal comes at week six when somebody realises this person still can't do the thing they were hired to do.
Best tools for Onboarding & LMS
The real problem isn't that the first day was badly organised. It's that the first day was the only part anybody designed. Onboarding gets built as an event because an event has a date and an owner, while the weeks that actually determine whether somebody becomes productive have neither. Everything that matters happens in the part nobody scheduled.
When You Genuinely Do Not Need to Act Yet
Your current setup is genuinely fine. New people reach the productivity you expected on roughly the timeline you expected, nobody has been blocked waiting for access, and if you asked a recent starter what was confusing they'd struggle to name much. That's rare and it means whatever you're doing works.
Friction is starting to show. A new starter has asked a colleague something they should have been told, or somebody spent their first week without the access they needed, or a manager has mentioned that onboarding took longer than they'd planned for. Each is small. The cheapest check is to ask your last two hires what they wish they'd known in week one.
It has become a real cost. People are taking noticeably longer to become useful than the role should require, or somebody left in their first months, or the same questions reach the same colleague from every new arrival. At this point the absence of structure is costing you real time, mostly from people who have other jobs.
The edge case that forces it. You're hiring several people at once, or into a team that's already stretched, or remotely for the first time. All three remove the thing most informal onboarding depends on, which is a colleague with enough slack to absorb the questions. The same applies where role-specific compliance or certification is involved, and requirements there differ by jurisdiction and sector, so establish what applies to you and take local advice.
Five Questions This Reader Asks at 11pm
How long should onboarding last? Longer than the first week and shorter than people say when they want to sound thorough. The honest answer comes from the role: onboarding ends when somebody can do the core of the job without needing help to get unblocked, which might be weeks in a straightforward role and months in one that depends on context. Set the period from the job rather than from a policy.
Who owns it? The manager owns whether it works. HR owns the parts that repeat across every hire, and somebody senior should own the process itself so it improves rather than being reinvented. The most common failure is HR owning the whole thing, which produces excellent administration and a new person with nothing to do on Tuesday.
What should happen in the first week? Less than you'd think, and more of it real. The instinct is to fill the week with sessions, and what actually helps is a small piece of genuine work, early, with somebody available to unblock it. People learn an organisation by doing something in it, and the first completed task does more than any amount of explanation.
How is this different from orientation? Orientation is the introduction, usually a day or less, covering who we are and where things live. Onboarding is the whole period until somebody is productive. Conflating the two is why so many organisations believe they have a process when what they have is a day.
What do I do if somebody's struggling at week six? Find out whether it's information, access or confidence, because they look identical from outside. Somebody who doesn't know something, somebody waiting on a permission nobody chased, and somebody who knows but isn't sure they're allowed to act all present as a person who isn't progressing, and the three need completely different responses.
Three Honest Categories the Approaches Split Into
Event-led, organised around scheduled sessions. A programme of inductions, briefings and training spread across the early weeks. It's right where the same knowledge genuinely has to reach everybody, where there's regulated content to deliver, and where several people start at once so the economics work. It fails because sessions transmit and don't embed: somebody who's been told about a system in week one, and doesn't touch it until week five, has effectively not been told. It also fills the calendar, which feels like progress and crowds out the real work that would actually teach them something.
Work-led, organised around doing something real. The new person is given a genuine small piece of work early, with support, and learns the organisation through completing it. It's right almost always, because it produces the only reliable teacher, which is doing the thing and getting it wrong in a low-stakes way. It also gives both sides an early, honest signal about how this is going. It fails when the work chosen is too large, when nobody has time to support it, or when the first task is something nobody cares about, which teaches a new person that their work doesn't matter.
Person-led, carried by a buddy or the manager. Somebody is made responsible for the new arrival and handles whatever comes up. It's right in small organisations and it's the most adaptive approach, because a person can answer the question actually being asked rather than the one a programme anticipated. It fails on capacity and consistency. It works beautifully when the assigned person has slack and badly when they don't, and since nobody plans for onboarding to coincide with a busy period, that's most of the time.
Five Diagnostic Questions You Can Self-Assess Against
Ask your last two hires what they wish they'd known in week one. Do it separately, and do it before they normalise, which happens faster than people expect. The answers are usually specific, usually small, and usually the same things, which means they're fixable once rather than repeatedly.
What did your last new starter do on their second Tuesday? Not the first day, which is designed, but the first ordinary day after the attention stops. If nobody can say, that's the gap. Most onboarding failures are located precisely there.
How long before they completed something real? Trace it. The interval between arriving and finishing a genuine piece of work is the single best indicator you have, both of how well the process works and of how the person is doing. A long gap is almost never about the person.
Which questions reach the same colleague every time? There's usually one person in every team who answers everything for new arrivals, and they're carrying an invisible load. The list of things they get asked is your missing documentation, written for free by the people who needed it.
Was anybody waiting on access? Check the last few starters. Access delays are the most common, most preventable and most demoralising onboarding failure, because the person can see exactly what they can't do and has no way to fix it themselves.
Six Ways Onboarding Gets Structured, Reviewed
A first-day agenda with nothing after it
The day is planned in detail and the following weeks aren't. It earns its place as better than nothing, and the effort is genuine: somebody has thought about the arrival, arranged introductions, and made the first hours feel considered. That matters, and people remember it.
Where it falls short is everything after. The day creates an expectation that the organisation is organised, which the second week contradicts, and that contrast lands harder than if nothing had been arranged at all. It also gives everybody involved the impression that onboarding has been handled, so nobody is looking at week three.
If this is what you have, the cheapest improvement isn't a better first day. It's writing down what should happen in each of the next four weeks, even roughly.
There's a version of this that does more harm than an ordinary first day, which is the elaborate welcome. Where the arrival is unusually well produced, the contrast with the following week is sharper, and the new person reads it as a gap between how this place presents itself and how it operates. A modest first day followed by a structured second week lands considerably better than the reverse.
A fixed programme of sessions over several weeks
A scheduled series of briefings, training and introductions. It earns its place where content genuinely must reach everybody, where regulated material has to be delivered and recorded, and where cohorts start together so the sessions are economic. It also guarantees that certain things happen, which informal approaches don't.
It falls short on retention and on timing. Information delivered before somebody needs it doesn't stick, so a comprehensive programme front-loads knowledge into exactly the period when it's least likely to be absorbed. It also consumes the new person's time, which means less contact with the real work, and the real work is what actually teaches them.
Keep the sessions that genuinely need to be sessions, move everything else to the point of need, and accept that some of it belongs in a document rather than a meeting.
The test for whether something needs to be live is whether the value is in the questions. A session where people ask things and get answers specific to their situation earns the time. A session where somebody presents and nobody interrupts is a document being read aloud, and it will be retained about as well as a document nobody read.
A checklist owned by the new person
The starter holds a list of things to complete, read, request and meet. It earns its place by giving somebody agency on days when they'd otherwise be waiting, and by removing the need for a colleague to remember every item. People generally like having something to work through.
It falls short when the list is a substitute for attention. A person working through a checklist alone is occupied rather than supported, and the items that matter most, which are the ones involving other people, are the ones a new starter has least ability to chase. It also fails when items depend on somebody else acting, since the new person then owns something they can't complete.
Give them the list for what they can do alone. Keep the items that depend on others with the people who can actually move them.
There's a second benefit to splitting it that way, which is diagnostic. If the new person's list is complete and the organisation's list isn't, you've learned something specific about where your process breaks, and it's usually the same few items every time. That pattern is invisible when everything sits on one undifferentiated checklist.
A buddy or mentor carrying most of it
One colleague is made responsible for the new arrival. It earns its place as the most adaptive option, because a person answers the actual question rather than an anticipated one, and because having somebody obvious to ask removes most of the hesitation that slows a new starter down.
It falls short on capacity. Assigning a buddy without reducing their other work means onboarding competes with their day job, and the day job wins, usually just when the new person's questions get harder. It also varies enormously: two people starting the same week can have completely different experiences depending on who they were paired with.
It works where the buddy has genuine slack, where the pairing has a stated purpose, and where the manager hasn't quietly delegated their own responsibility along with it. That last failure is the common one and it is rarely deliberate. A manager who has assigned a buddy feels the arrival is covered, so the things only a manager can provide, meaning the work itself and the authority to act, arrive later than they should.
Learning by doing real work from the start
The person is given something genuine and small in the first days, with support available. It earns its place because it's how people actually learn an organisation, and because it produces early information for both sides: the new person finds out what the work is really like, and the manager finds out what they can do.
It falls short when the support isn't there, which turns the same design into abandonment. It also fails when the first task is chosen badly: too big, and they flounder for weeks; too trivial, and they conclude the job isn't what they were sold. Choosing well takes a manager half an hour of thought and it's the highest-value half hour in the whole process.
The version that works is a real task with a genuine deadline, small enough to finish in days, with somebody named to unblock them.
It also helps if the task touches several parts of the work rather than one. Something that requires them to use two systems, ask one person a question and produce something another person will look at teaches more about how the place runs than a task performed entirely alone, even if the alone version is technically more useful.
No deliberate structure at all
The person arrives and things happen as they happen. It earns its place more often than it should, in very small organisations where somebody works alongside the new arrival constantly and the learning is genuinely continuous.
It falls short as soon as that proximity isn't there. Without structure, what a new person learns depends entirely on who happened to be free, and what they don't learn is invisible until it causes a problem. It also puts the burden of asking on the person least equipped to know what to ask.
The minimum worth having isn't a programme. It's a written answer to three questions: what should they be able to do by when, who unblocks them, and what is their first real piece of work. Those three take half an hour to write and they survive a chaotic week, which is the real test. Anything longer tends to be abandoned the first time the team is under pressure, which is usually the week somebody starts.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| People productive on the expected timeline | Any | Any | None | Leave it alone |
| First day designed, nothing after it | Any | Any | Week two is empty | Write down weeks two to five |
| Same questions reach the same colleague | Any | Any | Undocumented knowledge, carried by one person | Write down what they get asked |
| Somebody spent a week without access | Any | Any | Preventable, and visible to the new person | Access requested before the start date |
| New starters busy but not progressing | Any | Session-heavy programme | Sessions crowding out real work | A real task in week one, with support |
| Buddy assigned, experience varies wildly | Any | Any | Capacity, not willingness | Reduce the buddy's other work, state the purpose |
| Several people starting at once | Any | Any | No colleague has slack to absorb it | Cohort sessions for the common parts only |
| Onboarding remotely for the first time | Any | Remote | Everything unscheduled disappears | Deliberate contact, and write more down |
| Role has regulated or certified content | Any | Regulated sector | Requirements differ locally | Establish what applies, take advice |
The second row is where most organisations actually are, and the fix is unglamorous. Writing down what should happen in weeks two through five, even in rough form, addresses more of the problem than any redesign of the first day.
What the New Person Actually Needs, in Order
Needs arrive in a sequence, and delivering them out of order wastes most of the effort. Something given before it's needed isn't retained, and something given after it's needed has already cost somebody a week.
| The need | When it becomes urgent | What happens when it arrives late |
|---|---|---|
| Access to systems and tools | Day one, before anything else | They can see what they cannot do, and cannot fix it |
| Somebody obvious to ask | Day one | Questions go unasked, and the gap compounds silently |
| What they are meant to be working on | Day one or two | Busy-looking work, chosen to fill time |
| A real task they can complete | First week | Nothing is learned, because nothing was done |
| How decisions actually get made here | Weeks two to four | They escalate wrongly, or fail to escalate at all |
| Who does what across the organisation | Weeks two to six | They ask the wrong people and conclude nobody knows |
| Why things are the way they are | Weeks four onwards | They propose changes that were tried, and lose credibility |
| The unwritten rules | Continuously | They breach one and find out by somebody's reaction |
The first row is the one that causes the most avoidable damage and it's almost entirely a scheduling problem. Access requests raised on somebody's first day take as long as they take, and the person spends that period unable to work while watching everybody else. Raising them before the start date costs nothing and removes the single most common complaint new starters have.
The seventh row is the one that matters most for people joining at a senior level. Somebody who doesn't know why the current arrangement exists will propose the obvious alternative, discover it was tried and failed, and spend credibility they hadn't yet earned. Telling people the history of the two or three things they'll definitely want to change is cheap insurance. It also signals something useful about the organisation, which is that the current arrangement was arrived at rather than inherited thoughtlessly. Somebody who hears the history is far more likely to propose a genuine improvement than the one that was already tried.
Measuring Whether Onboarding Worked
Most onboarding measurement is a satisfaction survey sent in week two, which tells you whether somebody enjoyed their first fortnight and nothing about whether the process worked.
The measure that actually means something is time to independent work: how long before this person completed something real without needing help to get unblocked. It's specific, it's observable, and it varies by role in a way you can account for. Track it across several hires and you'll see whether your process is improving, which no survey will tell you.
The second useful signal is what they had to ask for. Not the volume of questions, which is good rather than bad, but which questions they had to ask that the process should have answered. Collecting those from each new starter in month two builds, over a few hires, a precise list of what your onboarding is missing, written by the only people who can see it.
The third is whether anybody was blocked, and for how long. Waiting on access, on a decision, on an introduction that didn't happen. That's pure waste, it's entirely preventable, and it's invisible unless you ask directly, because new people are reluctant to report it.
What misleads is early satisfaction. A new starter asked how it's going in week two will say positive things, because they're new, keen and reluctant to complain, and because the first week is usually the best-organised part. The same question in month three produces a much more useful answer, and almost nobody asks it then.
One more thing worth watching, though it takes longer to read: whether people leave in their first months. That's a serious signal when it happens, and it's rarely about onboarding alone. It usually means the job differed from what was described, which points back at hiring rather than at the first weeks, so treat it as a prompt to look in both places. The question worth asking the person, if they will answer it, is which part of the job turned out to be different. That is far more actionable than a general enquiry about why they left.
What to Put in Writing
Onboarding knowledge is held in people's heads and rebuilt from scratch by whoever is handling the current arrival.
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| What they should be able to do, and by when | The manager | Before the start date | A process with no destination |
| Who unblocks them, by name | The manager | Before the start date | Questions nobody obvious can answer |
| Their first real task | The manager | Before the start date | A first week of looking occupied |
| Access needed, requested in advance | The manager, with IT | Before the start date | The most common and most visible failure |
| What each new starter had to ask for | The new starter, month two | Every hire | Rediscovering the same gaps repeatedly |
| The history behind the things they will want to change | The manager | Weeks four onwards | Credibility spent proposing what was already tried |
| What applies locally on checks and certification | HR, with local advice | Before hiring | Discovering an obligation after somebody starts |
The first three rows take a manager about half an hour before somebody arrives, and they address most of what goes wrong. The reason they don't happen isn't difficulty, it's that the start date arrives while everybody is busy with the work the new person was hired to help with.
Questions to Ask Before You Commit
On the destination. What should they be able to do without help, and by when? A bad answer describes what they'll have been shown.
On the empty day. What did your last starter do on their second Tuesday? A bad answer is that they were settling in.
On the first task. What real thing will they complete in week one, and who unblocks it? A bad answer is that they'll pick something up.
On access. Was anything requested before the start date? A bad answer is that IT usually turns it round quickly.
On the load. Which colleague answers every new starter's questions? A bad answer is that people help each other out.
On the gaps. What did the last two hires have to ask for? A bad answer is that nobody raised anything.
What Getting This Wrong Costs
The first cost is the weeks. Somebody hired to do a job and unable to do it yet is being paid to wait, and every week of unnecessary delay is a week of the thing you hired for not happening. That cost is real, it's large, and it appears in no report, because nobody measures the interval between arriving and being useful.
The second cost lands on the colleagues absorbing it. Where onboarding has no structure, it's carried by whoever is nearby and willing, usually the same helpful person every time, on top of their actual work. That's unpaid, unacknowledged and cumulative, and it's a reliable route to losing exactly the person you can least afford to lose. It also means the quality of somebody's onboarding depends on who happened to have a quiet week.
The third cost is the impression that forms early and is hard to shift. A person who spends their first fortnight unable to work, unsure who to ask and uncertain whether anybody noticed, has learned something about how this organisation operates, and they'll carry that reading into everything afterwards. It's also the period when somebody is still comparing this job to the one they left, which is a comparison you'd rather not invite.
So before you redesign anything, work out which of three problems you have. An information problem means people don't know things, and the answer is writing down what they keep having to ask. An access problem means they can't act, and the answer is requesting things before the start date. A structure problem means nobody owns the weeks after the first, and the answer is a manager spending half an hour before somebody arrives. Only the third feels like a project, and it's the smallest of the three.
When You Are Ready to Go Further
None of this needs a system. It needs a written answer to what they should be able to do by when, a named person who unblocks them, a real task waiting on day one, and access requested before they arrive.
The step beyond your own team is the repeat question. Most organisations rebuild onboarding from scratch for every hire, because the knowledge lives with whoever did it last. Collecting what each new starter had to ask for, in month two, produces a document written by the only people who can see what's missing, and after three or four hires it's the most useful onboarding material you have.
HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling actually supports here, our comparison work is one place to start.
Frequently Asked Questions
What is the onboarding process?
It's everything between somebody accepting a job and being able to do it without needing help to get unblocked. That's deliberately wider than most definitions, which stop at the paperwork and the introductions, and the wider version is more useful because it includes the part where onboarding usually fails. Most organisations design the first day carefully and leave the following weeks to whoever happens to be free, which means the period that actually determines whether somebody becomes productive is the one nobody planned. If you want a single test of whether you have a process, ask what your last new starter did on their second Tuesday.
How long should onboarding last?
Until somebody can do the core of their job without needing help to get unblocked, which depends entirely on the role rather than on any standard period. A straightforward operational role might reach that in weeks. One that depends on accumulated context about customers, systems or history takes considerably longer, and pretending otherwise just means declaring onboarding finished while somebody is still stuck. Set the expectation from the job, tell the new person what it is, and check against it rather than against a date in a policy.
Who is responsible for onboarding?
The manager owns whether it works, because they control the work, the access requests and the attention. HR owns the parts that repeat identically for every hire, which is mostly administration and anything regulated. Somebody should own the process itself so it improves between hires rather than being rebuilt each time. The common failure is HR owning the whole thing, which produces well-administered paperwork and a new person with nothing to do on their second day, since the parts that actually matter aren't HR's to arrange.
What should happen in the first week?
Less scheduled content than instinct suggests, and one real thing completed. The reflex is to fill the week with sessions, which feels thorough and mostly produces information delivered before it can be used. What teaches somebody an organisation is doing something in it: a genuine, small piece of work with a real deadline and a named person to unblock them. Choosing that task well takes a manager half an hour and it's the highest-return preparation available. Everything else in week one should be arranged around making that task possible.
How is onboarding different from orientation?
Orientation is the introduction, usually a day or less, covering who the organisation is, where things are and what the basics look like. Onboarding is the whole period until somebody is productive, which includes orientation and continues well past it. The distinction matters because conflating them is how organisations end up believing they have a process when what they actually have is a well-run day. If everything you'd describe as onboarding fits inside the first week, you have orientation.
How do you onboard somebody when the team is too busy?
Accept that it will be worse and decide deliberately what to protect, rather than hoping it works out. The three things worth protecting even in a bad month are access arranged before the start date, one named person who will answer questions, and a first task small enough to be supported. Everything else can slip. What causes real damage is the version where nobody decides, so the new person gets whatever attention is left over, which in a busy period is none, and they spend a fortnight concluding that this is what the job is like.
What do you do when a new starter is struggling at week six?
Work out which of three things it is, because they're indistinguishable from outside. It may be information, meaning nobody told them something and they don't know what they don't know. It may be access, meaning they're blocked on a permission or an introduction nobody chased and are too new to escalate it. Or it may be confidence, meaning they know what to do and aren't sure they're allowed. Ask directly and specifically, since a general question about how it's going will get a positive answer from almost anybody at week six.
How do you know whether onboarding is working?
Track how long it takes somebody to complete a real piece of work without needing help to get unblocked, and compare it across hires. That's specific, observable, and it tells you something an early satisfaction survey never will. Then ask each new starter in month two which questions they had to ask that the process should have answered, and keep the answers. After a few hires, that list is the most accurate description of what your onboarding is missing, and it's written by the only people positioned to see it. Avoid week-two satisfaction scores, which measure keenness rather than the process.
Almost every organisation designs the day and leaves the weeks. The weeks are where onboarding actually happens.
