First Months
Onboarding is bad almost everywhere for a structural reason
The people who could write good onboarding are precisely the people who can no longer remember needing it, and that explains most of what goes wrong.
By Tara Mukherjee3 min read
A predictable disappointment
Almost everybody’s first weeks are worse organised than they expected. The laptop arrives late, half the accounts do not work, the induction covers fire exits and the expenses policy but not what the team actually does, and the document you are pointed at was last edited before a restructure that changed the names of everything in it.
People tend to read this as evidence that they have joined a shambles. Sometimes that is true. More often it is the ordinary output of a well-known failure that repeats across organisations of every size and quality, and it is worth understanding, because the understanding converts frustration into a plan.
The curse of knowing
Good onboarding has to be written by somebody who knows the system. But knowing a system thoroughly makes it nearly impossible to remember which parts were confusing, because the confusion has been overwritten by fluency. This is a well-documented cognitive problem, and it applies with particular force to internal jargon, undocumented conventions, and the dozen small facts that everyone learned by accident.
So the expert writes down the things that feel like knowledge to them — architecture, policy, the formal process — and omits the things that are now invisible, such as which of the two systems with similar names is the live one, or who you actually have to ask for approval regardless of what the org chart says. Those omissions are exactly the material a new joiner needs, and they are the hardest for an insider to see.
Nobody owns the document
The second structural problem is ownership. Onboarding material sits in a gap: it is not any one person’s job, it produces no measurable output, and its cost of neglect is paid entirely by people who have not arrived yet and therefore cannot complain. Every incentive in a busy team points away from maintaining it.
Worse, it decays silently. A process document does not throw an error when it becomes wrong. It simply keeps existing, accumulating small inaccuracies with each change, until the accumulated drift makes it actively misleading — which is more damaging than having no document at all, because it wastes time and then produces a wrong belief.
You can see the same dynamic in how induction sessions are assembled. The parts that are legally required or centrally mandated get done reliably, because somebody is accountable for them. The parts that would actually help you do the job depend on a busy team volunteering effort for a benefit they will not personally receive, and unsurprisingly those parts are the ones that get skipped when the quarter is tight.
What to do with the first six weeks
The practical response is to treat yourself as an instrument. For a short period you can detect exactly which things are unclear, and that sensitivity is disappearing daily. Keep a running file of everything that confused you, every term you had to ask about, every place the documentation lied. Do not tidy it as you go; just capture.
Then, at around week six, turn it into something. A page of corrections to the existing notes, or a short "things I wish I had known" document for the next person, is genuinely valuable and costs you almost nothing to produce because you already did the hard part. It also solves a problem specific to new joiners, which is having something concrete to point at when someone asks what you have contributed.
Ask before you publish it widely, and keep the tone neutral rather than triumphant. "Here are the bits that tripped me up, happy to fold them into the main doc" lands very differently from an audit of somebody’s neglected work.
The distinction worth drawing
Bad onboarding is normal, but there is a line past which it stops being ordinary entropy and becomes a real signal about the place. Missing documentation is entropy. Nobody having time to answer a question all week is a resourcing problem. No named person responsible for your ramp-up after a month is a management problem. Colleagues who are actively unwilling to explain how things work is a culture problem, and it is the one that tends not to improve.
It is fair to raise this with your manager, and the framing matters. A complaint about the induction is easy to nod at and forget. A specific request — "I am blocked on getting access to X, and I do not have a clear owner for questions about Y" — is a concrete thing a manager can act on, and it also demonstrates that you are tracking your own progress rather than waiting to be developed. That last impression is worth more than the access.
Common questions
Should I complain about a bad onboarding experience?
Raise it as specific unblocked items rather than as a general grievance, and raise it early enough that it can be fixed for you rather than only for your successor. If there is an exit survey for the induction process, use it, but do not rely on it — those forms are frequently collected and rarely read.
Is it presumptuous to rewrite the team documentation as a new joiner?
Not if you offer rather than announce, and not if you stick to describing what confused you rather than judging what exists. The person who wrote the original was usually doing it in stolen time and will mostly be relieved. If they are not, you have learned something useful about the team.
How long should it take to feel competent?
Long enough that most people quietly panic somewhere in the middle. It varies far too much by role and by how much undocumented context a system carries to put a number on it, but a useful checkpoint is whether the things you are confused about have changed. Fresh confusions mean progress; the same confusion for two months means something is stuck and needs saying out loud.
Senior writer, After the First Job
Tara writes the explanatory pieces on first months, managing up, money at work and reads the small print so you do not have to.
