Every manager has a number in their head for this, and most of the numbers are wrong in the same direction.
Here are the questions people actually ask, answered as directly as I can.
How long does it really take?
For most knowledge roles: meaningful contribution somewhere in the first one to three months, genuine independence around three to six.
Senior and specialist roles take longer, not less, which surprises people. A senior hire has more context to absorb before their judgement is worth anything, and their value comes largely from judgement. Someone junior can be usefully closing small tickets in week three while still being a year from independence.
The spread around those numbers is enormous, and almost all of it is explained by onboarding quality rather than by the person. Which is the useful finding, because onboarding quality is something you control.
Why does it take so long?
Because most of what makes an experienced person effective at your company is not in your documentation.
Which service owns this. Why that abstraction is weird. Who to ask about billing. Which test suite lies. What was tried two years ago and failed. Which of the four ways to deploy is the one people actually use.
None of that is skill. It is context, and in most companies it lives in people's heads. Every time a new hire needs a piece of it, the task turns into a scheduling problem — find the person, wait for them, get thirty seconds of answer.
That is why documentation quality predicts ramp time more strongly than almost anything else. Not because reading docs is fast, but because it removes the dependency on someone else's calendar.
What does a struggling ramp look like?
Distinctive, once you know the shape.
Their week is heavily fragmented — lots of short bursts, few sustained blocks — because they are constantly stopping to find things out. Their tooling looks scattered: many applications, none for long. And there is a lot of low-intensity time that reads as activity but is really waiting.
A ramp going well looks different by about week four. Blocks lengthen. Tool usage concentrates on the few things the job actually needs. The pattern starts to resemble the rest of the team's.
If someone is still fragmented at week eight, something is wrong — and in my experience it is much more often a missing document or an unclear owner than the hire.
Should I monitor new hires more closely?
No. It is the wrong instinct and it costs you.
The first weeks are when someone is deciding whether they made a good decision joining. Closer scrutiny at exactly that point reads as distrust, and it is the kind of thing people remember and mention to their former colleagues.
What you actually want to know is whether they are blocked. There is a much better instrument for that: ask them, weekly, in a way that makes admitting confusion safe. "What's still unclear?" gets better data than any dashboard, and it costs ten minutes.
Where cohort-level data helps is spotting that every new hire hits the same wall in week three — which points at your onboarding, not at any individual. That is a systems question, and systems questions are what this data is good for. The general principle is in how to track employee productivity.
What actually speeds it up?
In rough order of impact:
A real first task, chosen in advance. Small, shippable in the first week, touching the systems they will live in. The confidence effect of shipping something in week one is disproportionate.
A named person whose job is answering their questions. Not "ask anyone" — a specific name, told in advance that this is part of their week. Ambient availability does not work remotely and barely works in an office.
Environment setup that works before they arrive. A day and a half lost to a broken toolchain in week one is both wasted time and a bad signal about how the place runs.
Writing down the answer every time they ask something undocumented. The new hire is the best documentation auditor you will ever have, and the window closes as soon as they stop noticing what is strange.
Does remote onboarding take longer?
Usually somewhat, yes — this is one of the few areas where the evidence for in-person is reasonably consistent, mostly because of the ambient-context effect.
But the gap is a design problem, not a law of nature. Remote teams that onboard well do it deliberately: written context, scheduled buddy time, explicit forums for the questions that would otherwise be asked over a desk. Remote teams that onboard badly are usually doing in-person onboarding with the in-person parts removed.
If you are weighing this into an office policy, the RTO evidence is worth reading — onboarding is a legitimate argument for some in-person time, and it is a much narrower argument than most mandates make.
How do I know if my onboarding is any good?
Pick three numbers and watch them by cohort: days to first merged change, weeks until the person's working pattern resembles the team's, and weeks until they stop needing their buddy daily.
Compare cohorts, never individuals. Ramp varies legitimately by role, seniority and what someone was hired to fix. Ranking new hires against each other is both unfair and uninformative.
Then act on the cohort finding. If everyone stalls in week three, go and find out what happens in week three.
ProdView shows working patterns at team and cohort level from activity metadata — enough to see whether a new joiner's week is settling into shape, without watching anyone individually. Free for three seats.