Your company has a really nice onboarding program. There’s a welcome package. A team lunch on the first day. A nice laptop that actually has the specs people need. Maybe a mentor assigned. A training plan. It’s all very thoughtful and it makes a good impression. And then the person’s first day ends and the operational reality sets in, and it turns out the nice parts of onboarding are almost entirely separate from whether the person can actually do their job.
I’ve spent a decade in learning and development and another stretch in operations, so I’ve seen this from both sides. HR and learning teams pour energy into the first-day experience because that’s what feels like onboarding. Breakfast with the team. Culture presentation. Handbook walk-through. All delivered with enthusiasm and professionalism. And then a new person sits down at their desk on day two and realises they don’t have access to the systems they need. Or they have access to some systems but not others. Or they’ve got seventeen different passwords written down on a Post-it because they don’t know how to request a password manager. Or they have to ask someone to give them access to the documentation because the documentation system isn’t in the handbook. Or they’re not quite sure who to ask for what, so they’re bothering people at random and feeling like they’re a burden.
Great onboarding is fundamentally an operational problem, not an HR problem.
The first operational requirement is system access. This seems obvious. It’s not being done well in most companies. The person’s start date is weeks away and their accounts still aren’t provisioned. Or they’re provisioned but the access is incomplete — they can access the product but not the documentation system. They can see the wiki but the wiki doesn’t have the information they need because it’s in someone’s Google Drive. They’re locked out of the Slack channel for their team. They’ve got a temporary password that requires them to change it immediately, and the password requirements are so strict that it takes them six tries to come up with something that works.
The second operational requirement is knowing the landscape. Who does what. Where decisions get made. What the actual decision-making process is versus what the handbook says it is. This cannot be learned in a training presentation. It requires a conversation. It requires context. It requires someone sitting down and saying, “Here’s how we actually work. Here’s who owns what. Here’s how you get things done. Here’s the unofficial process that nobody talks about but everyone knows.”
The third is documentation that’s actually findable and that actually works. Not five different documentation systems. Not an internal blog and a wiki and a Google Drive and someone’s personal notes. One place where things are documented. Clear labeling. A search function that works. Up-to-date information. Most companies have some kind of documentation system and it is almost always a disaster. It’s outdated. It’s incomplete. It’s not indexed properly so it’s impossible to find anything. A new person asks a question, gets told to check the wiki, looks in the wiki for ten minutes, doesn’t find it, and then asks someone else.
The fourth is understanding why things are the way they are. Why do we use this tool instead of that tool? Why does the process work like this? Why did we make this decision? This is context that prevents repeated questions and stupid decisions. Someone understands the constraints. They understand the history. They understand why something that looks inefficient actually makes sense given the tradeoffs. This usually only comes from a real conversation, not from training.
The fifth is clarity about what success looks like. What are they supposed to be doing? What does done look like? What does a good job in this role mean? How will they know if they’re succeeding? A surprising number of new people operate for weeks without clarity on what they’re supposed to be optimizing for. They’re trying to do a good job but they’re not sure what good looks like.
The operational onboarding that actually matters usually isn’t formalised. It’s someone from the team sitting down with the new person and walking them through their actual workflow. It’s someone checking in at the end of their first week and asking what they’re stuck on. It’s someone — maybe the manager, maybe someone else — having a conversation about how decisions actually get made in this company. It’s documentation being used and updated because a new person went looking for something and it wasn’t there.
The companies that get onboarding right usually do it by embedding the operational responsibility into the team or the manager, not by creating an onboarding specialist. The team knows they’re responsible for bringing someone up to speed. It’s not a separate project. It’s part of how they work.
They also usually have a specific person who cares about the onboarding experience. Someone who checks in with new people at the 30-day mark and asks, “What’s still confusing? What do you still not understand? What did the training miss?” And then they fix it. They update the documentation. They add a step to the process. They make a note that someone’s always confused about that part and maybe the training needs to address it more clearly.
The best onboarding I’ve ever seen happened at a smaller company that explicitly treated the first 90 days as a learning period and acted like it. New people had a schedule for their first month that actually carved out time for learning, not just getting thrown into the work immediately. They had a weekly check-in with their manager specifically about learning and understanding the role. They had a checklist of things they should understand by the end of day five, end of week two, end of month one, end of month three. It was specific. It was operational. It didn’t feel ceremonial.
The harder part is that good operational onboarding requires you to document things you’ve never thought to document. Why we use this tool. How we actually make decisions. What the communication norms are. What happens if you screw up. What the career path looks like. Most of this is just walking around in people’s heads and never written down because the people who know it have been here so long they don’t even think about it.
It also requires you to maintain it. When something changes, you update the documentation. When someone’s confused about something, you fix the documentation so the next person doesn’t have to be confused. A lot of companies invest in a beautiful onboarding program and then never touch it again, and five years later it’s completely outdated and nobody uses it.
The real test of onboarding is simple: can someone new to the company complete a real task, end-to-end, without constant help from someone else? Can they find the documentation they need? Can they figure out who to ask for what? Can they understand the decision-making process? If the answer’s yes to all of that, you’ve got good operational onboarding. If it’s no, it doesn’t matter how nice the welcome package was.
This matters for retention. People are more likely to leave in their first ninety days if they feel lost and confused than if they feel productive and confident. It matters for ramp time — how long it takes someone to be genuinely productive in their role. It matters for institutional knowledge, because when you document onboarding, you document the actual way the company works, not the theoretical way it’s supposed to work.
The payoff isn’t immediate or dramatic. It’s not a quarterly metric. But over time, it compounds. Good onboarding means people get productive faster. It means you spend less time answering the same questions over and over. It means new people can actually contribute instead of just consuming energy while they figure out how things work.
And it starts not with a better welcome package, but with someone giving enough of a damn to think about the operational reality of being new, and then actually building systems around that reality instead of hoping people will figure it out on their own.