The Onboarding Cliff Is a Comprehension Problem

Four months to productivity on a senior hire is roughly $60,000 spent on an activity nobody has defined or measured. It is not a hiring problem — it measures what understanding your system costs.

Written by Vladimir Miroshnichenko·Published August 21, 2026·Updated September 4, 2026·6 min read

Ask an engineering leader how long it takes a senior hire to become genuinely productive and you will hear something between three and six months. Ask what happens during those months and the answer gets vague — "ramping up", "getting familiar", "picking things up".

That vagueness is expensive. On a $180,000 loaded salary, four months to productivity is roughly $60,000 spent per hire on an activity nobody has defined, measured or tried to shorten. Hire ten people a year and it is a line item the size of a small team.

And it is not a hiring problem. It is the purest measurement of one thing: how expensive it is to understand your system.

What those months are actually spent on

Watch a new senior engineer closely and the time divides roughly into:

Learning the domain — what the product does, in the business's terms
Learning the map — where things live and how they connect
Learning the invisible — which parts are load-bearing, which look redundant but are not, why that guard exists
Learning the people — who to ask about what

Notice what is missing. Almost none of it is learning to code, and very little is learning the language or framework. You hired for that and they had it on day one.

Almost all of the ramp is acquiring context that already exists in the organisation — distributed across the code, a few people's heads, some stale documents, and old pull request threads. None of it is in a form that can be handed over.

That last clause is the whole problem. The knowledge exists. It cannot be transferred except by slow osmosis.

Why AI did not fix this

It is a reasonable expectation. A new hire has an assistant that has read the whole codebase. Surely the ramp collapses.

Mostly it has not, and METR's controlled trial hints at why. Sixteen experienced developers, working on repositories they knew well, were 19% slower with AI — while believing they were 20% faster. If AI does not reliably help people who already have context, expecting it to substitute for context is optimistic.

The mechanism is straightforward. An assistant reading your repository can answer what does this function do. A new hire's actual questions are different:

Why does the product behave this way — was it deliberate?
What will break if I change this?
What is safe to touch in my first month?
Who decided this, and is the reason still valid?

Those answers live between files, in decisions, in history. A tool working from fragments reconstructs them, and reconstruction is exactly where confident wrong answers come from. A new hire cannot tell a reconstructed answer from a grounded one — they have no model to check it against, which is why they are new.

So the assistant is most confident precisely where the newcomer is least able to catch it.

The senior tax

There is a second cost, and it is larger than the first.

Every question a new hire cannot answer alone is asked of somebody who can. Those people are your most expensive and most constrained. A four-month ramp does not cost one salary — it costs one salary plus a fraction of two or three senior calendars.

Teams feel this as "we can't onboard more than one person at a time", which is usually not about mentoring capacity. It is about the number of interrupts the two people who hold the system in their heads can absorb before their own work stops.

That is also why onboarding gets worse as a company grows. More surface area, same small number of people who understand how it fits together.

Measure the thing before improving it

Almost nobody tracks this properly. Three numbers, none of which need tooling:

Time to first meaningful contribution. Not first commit — anyone can fix a typo in week one. First change that a senior would have been assigned. This is your comprehension cost per person, in days.

Question volume and destination. For one month, ask new hires to log every question they had to ask a person. Count them, and note how many had an answer that existed in the code. That second number is what could have been self-served.

Interrupt cost. For the same month, ask the two or three people who get asked the most to record time spent answering. That is your senior tax, and it is usually the larger figure.

Most teams that run this discover the ramp is longer than they believed and that a majority of questions had answers already sitting in the repository — findable in principle, not findable in practice.

What actually shortens it

Answer the domain first, the code second. Newcomers who learn what the product does before touching the code contribute sooner. The reverse order produces engineers who can navigate files and cannot judge consequences.

Make the invisible explicit. The load-bearing oddities are the expensive part. Every time somebody explains one in Slack, that explanation should land somewhere durable — otherwise it is re-explained to the next hire and the one after.

Give them something they can interrogate, not read. A wiki is a monologue written for a reader who does not exist yet. A source they can put their own questions to serves the actual sequence of a newcomer's confusion, which is unpredictable and personal.

Insist on evidence. A new hire cannot evaluate an unsupported claim. An answer that cites the file it came from can be checked by someone with no context at all — which is the only kind of answer that is genuinely useful in month one.

Track the invisible questions. The ones a new hire does not ask because they do not know to ask them. These surface as mistakes in month three. Every such mistake is a documentation gap with a return address.

The reframe worth taking to a planning meeting

Onboarding time is not a property of your hires. It is a property of your system's legibility, and it is the number that tells you what understanding costs in your organisation — not for new people, for everyone.

Because the same cost is being paid every day by people who have been there for years: when they move between areas, when they return to code they wrote a year ago, when they are asked whether a change is risky. Onboarding just makes it visible by concentrating it into one person over one measurable period.

Shorten it and you have not only improved hiring. You have reduced what it costs your whole company to know what it built.

Put a number on your own workflow

Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.

Build My Business Case → Start free →

Frequently asked questions

Why does onboarding a senior engineer still take three to six months?

Because almost none of that time is spent learning to code. It goes on acquiring context that already exists in the organisation — what the product does, which parts are load-bearing, why decisions were made — distributed across code, a few people's heads and stale documents, in a form that cannot be handed over.

Hasn't AI shortened onboarding?

Less than expected. Assistants answer "what does this function do" well; a newcomer's real questions are about consequences, intent and safety, which live between files and have to be reconstructed. And a new hire cannot tell a reconstructed answer from a grounded one, because having no mental model is what makes them new.

What should we measure about onboarding?

Time to first meaningful contribution — a change a senior would have been assigned, not a typo fix. The number of questions new hires must ask a person, and how many had answers already in the code. And the time senior engineers spend answering, which is usually the larger cost.

Why does onboarding get harder as a company grows?

Surface area grows while the number of people who understand how it fits together does not. The constraint is not mentoring capacity but how many interruptions those few people can absorb before their own work stops — which is why teams often cannot onboard more than one person at a time.

What is the fastest way to shorten ramp time?

Teach the domain before the code, capture the load-bearing oddities somewhere durable the first time they are explained, give newcomers something they can question rather than a document to read, and insist every answer cites its source — since a person with no context can check a citation but cannot evaluate a bare claim.

Vladimir Miroshnichenko

Founder, GitMir

Founder of GitMir, the intelligence layer that gives AI real context about a company's software. I write about AI agents, context engineering, workflow economics and keeping AI-generated work under control.

LinkedIn →

← More articles