Why new engineers take months to be useful, and what the wiki doesn't tell them

A strong engineer joins on Monday. By Wednesday she has the repository running, and by Friday she has read the payments service end to end. She understands every function. Then she opens a pull request, and a reviewer says: “Don’t touch that check. It’s there because of something that happened in 2021.”

She had no way to know. Nothing in the code, the wiki or the ticket history says what happened in 2021. The person who does know is busy, so she asks a colleague, who thinks it was something to do with a partner, and who suggests asking someone who left.

This is what most of the “ramp-up” period in an established system actually is. It is less about learning the code than about learning which parts of it are deliberate.

How long does it really take a new engineer to become productive?

Longer than most plans assume, and it varies a lot between companies. Pluralsight’s analysis of engineering data, covering more than two thousand engineers, reported an average ramp of about six months, with one group of companies at three to four months and another at eleven to twelve¹. DX, which tracks developer experience, measured how long new hires at six large enterprises took to reach their tenth pull request, and found a gap of roughly 91 days for people who did not use AI tools daily against 49 for those who did².

Treat both with care. They come from vendors, they measure different things, and neither tells you why one company ramps in a quarter while another takes a year. But the spread is the interesting part. Same job title, same languages, same kind of work, and a threefold difference in time to independence.

Our reading, which is an interpretation and not a finding from those studies: the difference is rarely about how well the code is written. It is about how much of the reasoning behind the code a newcomer can get without interrupting someone.

What is a new engineer actually waiting for?

Watch a new hire for a month and the blockers fall into a few groups.

• Intent. Why is the limit 30 days? Why does this region skip the check? Is this branch dead or protecting something?
• Hidden coupling. Which other service quietly assumes this value never changes?
• History. Which outage, audit or customer escalation produced this rule?
• Ownership. Who decided this, and are they still the right person to ask?

None of these can be answered by reading more code. An engineering leader who wrote about this in 2026 described a new hire, a strong programmer, working at roughly a fifth of her capacity for three weeks because she did not know about an outage-driven database change, a rewritten authentication module or a coupling between two services. His rough estimate was that a team of twenty hiring four people a year loses two to three engineer-months to knowledge transfer alone³. That is one person’s estimate from an AI-tools founder, not a measurement, but it matches what many engineering managers will tell you privately.

The cost is split in a way that hides it. The new hire is slow, but so are the two or three senior people who answer the same questions, and so are the reviews that stall on unwritten conventions. We have written about the wider cost of understanding rather than building. Onboarding is where that cost becomes visible, because it happens on a calendar you can see.

Why doesn’t the wiki solve this?

Every team has tried. A wiki helps with setup, architecture diagrams and “how do I deploy”. It fails on the questions above for three reasons.

It is written by people who no longer notice the question. The engineer who built the hold on large refunds does not think “why do we hold large refunds” is a question. Documentation records what its author found worth explaining, and the author’s blind spots are the new hire’s blockers.

It is written once. The page was right in 2022. The code changed twice since. Nothing marks the page as out of date, so the newcomer cannot tell which paragraphs to trust. Documentation goes stale because nothing connects it to the thing it describes.

It does not say who to ask. Even a correct page rarely names the person who made the decision. The new hire is back to asking around.

Can’t an AI assistant answer these questions?

It answers some of them well, and teams reporting faster ramp-up with AI tools are probably telling the truth about that. An assistant can summarise a service, trace a call path and explain an unfamiliar framework in seconds. That removes a real share of the waiting.

What it cannot do is supply a reason that was never recorded anywhere it can look. Several practitioners describe the same result: the assistant gives a new hire a structurally accurate explanation of the system and then misses why the system is the way it is. The newcomer then has a confident, fluent, incomplete picture, which is arguably worse than a visible gap. We covered the sharper version of this in why AI tools get your business rules wrong.

So a faster reader of code does not remove the underlying need. It makes the missing reasons more noticeable.

What does a new joiner need on day one?

If you strip the problem down, a newcomer needs the same four things an experienced engineer needs before changing a business rule:

1. The rule and where it lives.
2. The reason it exists, in the words of the person who decided it.
3. The owner, so questions go to the right person the first time.
4. A signal for how much to trust the answer: confirmed by the owner last month, or a guess from a commit message?

The fourth is the one most onboarding material skips. A page that sounds equally confident about everything teaches a new hire to trust everything, and the first wrong guess costs far more than a visible “nobody knows yet”.

Where organizational memory fits

This is the situation AppThentic’s onboarding page describes. AppThentic reads a company’s code, finds the business rules in it, asks the person who owns each rule why it exists, and keeps the answer with its source, owner, date and status. That record is Organization Memory.

For a new joiner, the documented behaviour is straightforward. They can ask why a rule exists and get the owner’s approved answer with its source. They can see which rules in their area are Unknown or Stale before relying on them, find who owns a rule, and read a rule’s timeline: what changed, when, and who decided. Questions go through Asking AppThentic, and the answer says plainly what is unknown instead of filling the gap with a plausible reason.

The statuses matter most here. An Approved answer was confirmed by the rule’s owner. An Inferred one is AppThentic’s own reading and, per the docs, should not be relied on for a decision. Unknown is recorded as unknown. That is the signal a wiki cannot give: how far to trust each answer.

For managers, the docs describe two further uses: pointing new joiners at their area’s rules instead of a stale wiki, and seeing which questions new joiners ask most, which shows where the memory is thin. Answers are kept current through keeping answers current, so the record is re-checked when the code or the reason changes.

Two honest limits. Organization Memory only holds an approved reason once the owner has approved it, so a freshly connected system will show many Inferred and Unknown rules at first. And it covers business rules and the reasoning behind them. It does not replace setup guides, runbooks or mentoring.

What can you do this week?

You do not need new tooling to find out how big your own gap is.

1. Ask your most recent hire to list the five questions they most wanted to ask and could not easily answer. Do this before the answers fade from memory.
2. For each one, note who finally answered it and how long it took.
3. Check whether that answer is written down anywhere today.

If the answers live in two or three people, you have found your single points of failure, and they are the same people described in what happens when the only engineer who understands a system leaves. Onboarding is simply the earliest, cheapest place to notice.

If you want to see how this looks on your own systems, book a walkthrough.

Sources