Most onboarding reviews I've sat in eventually land on documentation. The docs are stale, the wiki is a graveyard, someone volunteers to rewrite the handbook. Six months later a new hire spends two weeks reading an accurate handbook and still can't do anything.
I've built and hired for a globally distributed team spread across enough time zones that there was no single hour when everyone was awake. That spread is unforgiving, because it removes the thing most onboarding quietly depends on: an experienced person sitting nearby who can unblock you in thirty seconds. Take that away and you find out what your onboarding actually is. In our case it was a pile of documents plus a lot of waiting.
The fix wasn't better documents. It was working out who owned the things a new person needs, and discovering that in several cases the answer was nobody.
The clearest version of this came from outside HR
At Veodyn we audited the quality of public transit data feeds across Southern California. Going in, we expected the small, under-resourced agencies to have the broken feeds and the large ones to be fine. That's not what we found. The largest and best-resourced agencies also had feeds that were missing, stale, or malformed.
The failure wasn't capability. Those agencies employ people entirely able to publish a valid feed. The failure was that registering the feed and validating it were nobody's named job. Everyone assumed it sat with someone else, and the work fell through a gap that no amount of skill or budget closes, because skill and budget were never the constraint.
Onboarding fails the same way. Ask who owns provisioning access to the third system your new analyst needs, or who owns confirming they can actually run the thing locally, or who owns deciding what their first real piece of work is. In most organizations at least one of those has no name attached. It has a process attached, which isn't the same thing, because a process can't be asked a question or held to a date.
What to change
Start by naming an owner for each dependency rather than a stage. "IT provisions accounts" is a stage. "Priya provisions accounts and confirms login by day one" is an owner. Stages absorb failure quietly; a named person tends to notice when the thing didn't happen.
Then make the first week produce something real. Not a training exercise, not a tour. A small change that goes into the actual product or the actual dataset, chosen and scoped before the person starts. This was the highest-leverage change we made, because it converts onboarding from consumption into work and surfaces every broken dependency immediately rather than in week five when someone finally needs the credential nobody issued.
Picking that first task in advance is real effort for the manager, and I'll be honest that this is where the practice usually collapses. It gets skipped, and then week one becomes reading again.
The last piece is writing down decisions with their reasoning attached, not just the outcome. In a distributed team this is what lets a new person reconstruct context without waiting eight hours for the one human who remembers. The reasoning matters more than the decision, because a new hire who knows why you chose something can tell when the conditions have changed. A new hire who only knows what you chose has to treat it as scripture.
Why this reads as engagement
The reason I'd file this under engagement rather than logistics is what changed in behavior.
People stopped asking permission for things they were already allowed to do. That was the visible shift. When it's discoverable who owns what and why the current arrangement exists, a competent person just proceeds. When it isn't, the safe move is always to wait and ask, and a team where waiting is the safe move looks disengaged from outside while being entirely rational from inside.
Almost nobody is disengaged because the mission wasn't communicated compellingly enough. Plenty of people are disengaged because they spent three weeks unable to do the job they were hired for and drew the obvious conclusion about how much their time was worth here.
The limits of this
I can't give you a retention number for any of it. We didn't run a controlled comparison and I'm not going to invent one after the fact. What I can report is the change in behavior above, and that the volume of "who do I ask about X" messages dropped enough to be noticeable.
The ownership approach also has a cost the documentation approach doesn't. Naming owners means somebody's name is attached when it doesn't happen, and some managers will resist that, correctly identifying it as accountability. A handbook rewrite is more comfortable precisely because it spreads responsibility around until nobody holds any. If your organization won't tolerate named owners, this won't work, and I don't have a version that survives that constraint.
So before you rewrite anything, list what a new hire needs in week one and put a person's name next to each item. The gaps will be obvious, and they'll be the same gaps that have been quietly costing you every hire for years.
