Output Ramps in Weeks Now, Judgment Still Takes Months

How long should a new hire take to get up to speed?

Days to weeks for usable output, and months for unsupervised judgment, which is why one number has stopped working. Usable output means work that reads finished, and it now arrives that fast across a lot of knowledge work. Unsupervised judgment means you no longer read the work before it leaves the building, and that is the figure a headcount plan should be built on. The gap between the two is where the expensive surprises live.

The first number moved because short, self-contained tasks got much faster. In a pre-registered experiment, 444 college-educated professionals did occupation-specific writing tasks; the half given ChatGPT finished 10 minutes faster, 37%, than a control group averaging 27 minutes, and graders scored their output 0.45 standard deviations higher, with the largest gains going to the weakest writers ². Mid-level professional writing, done once, online, for pay, with no colleagues and no revision cycle. That is a narrow setting, and the narrow setting is the point: it is a good description of a new hire's first assignment.

The second number did not move, because it is made of something else. Knowing which of this team's conventions a generic answer violates is learned from people, from being corrected, and from watching a decision go wrong. Nothing in the tooling shortens that, and a team whose conventions live in people's heads rather than in writing will always ramp slower and will usually blame the hire.

So quote both or quote neither. A single ramp number now averages a thing that takes two weeks with a thing that takes two quarters, and the average describes nobody.

Where did the eight-month number come from?

A March 2012 online survey of 500 US HR professionals, sponsored by a relocation company. It reports eight months on average, with 27% of companies saying a year or more and 25% saying three months or less, and 58% of respondents saying their company does not measure new-hire productivity at all ¹. That last figure is the one that decides how much weight the first can carry.

Look at how the number was collected. The sample is 500 HR professionals recruited online across 49 states and the District of Columbia, none of them the hires being described. There is no definition of fully productive anywhere in it. The sponsor is a moving company with a commercial interest in workforce mobility. And it is from March 2012, which predates widespread remote work, the current tooling, and generative assistants entirely ¹.

That provenance does not make the figure a lie. It makes it a self-report about a quantity most respondents admitted they do not track. Cite it for what HR leaders believed in 2012, and keep it out of a hiring plan. The companion figure from the same panel, that companies lose on average 23 percent of new hires before the one-year anniversary, is self-report from the same 500 people and carries every one of the same problems ¹.

The general lesson is worth more than the specific number. Every widely quoted ramp benchmark traces back to a survey of managers, and vendor pages repeating them treat the figure as a property of roles when it is a property of a measurement year.

Measure the week you stopped checking their work

Open the calendar and the review history for your last three hires and find the week their work started going out without you reading it first. That date is a measurement rather than an impression, it lives in systems you already have, and it is specific to your team, which is the point: ramp time is largely a property of how much of your context is written down.

Where the date actually sits, by function:

• Engineering. The first week of pull requests approved with no changes requested, by someone other than the person who onboarded them.
• Client-facing work. The first email or deck that went to a customer without a draft review.
• Analysis and finance. The first model or memo that reached a decision-maker unedited.
• Operations. The first week they closed a category of exception without escalating one.

Three hires gives you a spread, and the spread is the useful output. If it is eleven weeks, four weeks and thirty weeks, the variance is telling you about three different managers or three different amounts of written context, and that is a more actionable finding than any industry average.

Do not substitute asking people. In a randomized trial, 16 experienced open-source developers completed 246 real tasks on mature repositories they had worked on for about five years; allowing early-2025 AI tools made them 19% slower, after forecasting a 24% speedup beforehand and still estimating a 20% speedup afterwards ⁴. Sixteen developers in one setting, on codebases they knew intimately, so the magnitude does not transfer. What transfers is the gap: people misjudge their own productivity badly enough to get the sign wrong. A manager recalling when a new hire became self-sufficient is making that same kind of estimate about their own reviewing habits. Read the date off the calendar.

Why does a fast ramp mislead a headcount model?

Because the thing that ramped is not the thing the model is counting. A plan assuming full contribution at month eight, confronted with finished-looking work in month one, pulls the next requisition forward and books capacity that still needs checking. The hole shows up whenever somebody finally looks, which is later than it used to be, and the correction lands in the quarter the plan already spent.

The underlying failure, confident work that turns out wrong, has been measured in a cleaner setting. In a field experiment, on one task deliberately chosen to sit outside AI capability, consultants using GPT-4 were 19 percentage points less likely to reach the correct answer: 84.5% of the control group got it right, against 60% and 70% in the two AI conditions ³. One task, one sample, a 2023 model, and the frontier moves with every release. The durable part is that consultants at a top firm could not tell which side of the capability line the task sat on, and neither can a new hire in month one, and neither can the manager reading the output.

So the constraint is reviewing capacity. If a team can generate three times the drafts and check the same number, hiring the fourth producer buys less than the model says. Count the second number when you plan the requisition, and read what it means to hire for verification rather than production before you write it.

Two cases deserve their own answer. Early-career hires who have never worked without an assistant ramp fastest on output and slowest on the check, which is a training problem: what to do when new grads never learned to work without AI. And a ramp that looks unusually fast and then stalls is often not a ramp problem at all, which is how to tell which of three failures you are looking at.

See the benchmarks >