§ CAPABILITY

Engineering Onboarding and Ramp-Up

A new engineer productive in weeks rather than a quarter. A plan with named outcomes at thirty, sixty and ninety days, and an environment that works on the first morning.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call How the work runs

What you're seeing

A new engineer's first two days are spent getting the application to run.
Usually means Setup is a sequence of undocumented steps that existing engineers have absorbed. The new joiner is the only unbiased measurement of it, and everyone else is paying the same cost invisibly.
New hires take a quarter to contribute independently.
Usually means There is no ramp plan, so the first month is spent discovering what nobody wrote down. It costs roughly what a failed hire costs, and nobody counts it.
The onboarding document was last updated two reorganisations ago.
Usually means It is nobody's job, so it decays until it is actively misleading. A wrong onboarding document is worse than none, because the new person follows it.
A buddy was assigned and had no time allocated.
Usually means The assignment was a name on a document. The new joiner then asks nobody, discovers things slowly, and forms the view that this is a place where you work it out alone.

Ramp cost is real and uncounted

An engineer who takes a quarter to contribute independently costs approximately what a failed hire costs.

The difference is that a failed hire is visible and this is absorbed. The salary is paid, the team’s capacity is reduced by the help they are giving, and the roadmap assumed a contributor who is not one yet. None of it appears anywhere as a number, which is why onboarding is chronically underfunded relative to recruiting.

That is the argument for treating it as part of the hiring system rather than as an administrative afterthought. Everything spent shortening the ramp is spent on capacity that has already been paid for.

Day one, and what it reveals

A working environment and a first commit on the first day.

Where that is not achievable, the finding is not about onboarding. It is that setup takes two days for everybody and the existing team has absorbed it — they know which environment variable is missing from the documentation, which service starts first, and which step to skip. The new joiner is simply the only person who cannot route around it, which makes their first morning the most honest measurement of developer experience available.

So the onboarding work and the platform work meet here, and fixing it pays out to the whole team rather than to the next hire.

Outcomes, not activities

“Understands the codebase” cannot be assessed, so it is never assessed, and the plan stops being referred to by week three.

“Ships small changes independently by day thirty. Owns the billing service by day sixty. Takes on-call by day ninety.” Each of those is checkable by both sides, and that is what makes the plan useful in the direction that matters most: a target missed at week six is early information — about the hire, or about the environment, or about the plan being unrealistic — and all three are cheaper to act on then than at month five.

Where it sits

This capability sits under Engineering Hiring, as the far end of the same system that starts with a role definition, and under Software Development, where a team being built needs people productive inside the engagement rather than after it.

It meets two neighbours. Developer Experience is where day one actually gets fixed — the environment, the setup, the paved path — and the two are frequently the same piece of work. And Career Ladders is what the ninety-day outcomes should be anchored to, because a ramp target for a senior engineer and for a mid-level one are different targets and the level is what says how.

How the work runs

  1. Fix day one

    A working environment and a first commit on the first day. Where that is not possible, the setup itself is the finding and it is affecting everyone.

  2. Name the first change

    A real, small, shippable piece of work chosen in advance. Reading documentation for a week teaches less than shipping something in two days.

  3. Write the 30-60-90

    Outcomes rather than activities. 'Owns the billing service on-call rotation' is a target; 'understands the codebase' is not.

  4. Assign a buddy with time

    A named person with the hours actually allocated. A buddy who is fully committed elsewhere is a name on a document.

What arrives

  • A one-command environment setup, verified by the next joiner
  • A curated set of first changes maintained by the team
  • A 30-60-90 template with outcomes per role and level
  • A buddy assignment with allocated time and a check-in schedule

What it costs your team

A day to build the first version, then around two hours per new joiner.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • Day one produces a working environment and a commit

    Costs Making that true is real platform work that competes with the roadmap.

    A first-day commit sets the expectation that shipping is normal and frequent here, and it is the fastest available proof that the environment works. Where a one-command setup is not achievable, that is not an onboarding finding — it is a developer experience finding affecting the whole team, and the new joiner just made it visible.

  • The first change is chosen in advance and is real

    Costs It requires the team to maintain a curated set of small, genuinely useful pieces of work.

    A week of reading documentation teaches less than shipping something small in two days, and it teaches the wrong thing about how this team operates. The change has to be real — a made-up task is transparent and it wastes the strongest signal a new person gets about whether their work matters here.

  • The 30-60-90 is written as outcomes, not activities

    Costs Outcomes are harder to write and they commit the manager to making them possible.

    'Understands the codebase' cannot be assessed, so it is never assessed and the plan quietly stops being used. 'Owns the billing service on-call rotation' can be. It also creates early information: a ramp target that is missed is a signal about the hire or about the environment, and both are worth knowing at week six rather than at month five.

  • The buddy has allocated hours

    Costs It removes real capacity from someone already delivering.

    A buddy with no time is a name in a document, and the new person correctly reads that as a signal about how much help is available. Allocating a few hours a week for the first month is a small, visible cost against a ramp that takes a quarter instead of six weeks.

Frequently Asked Questions

A written set of outcomes a new hire is expected to reach by their thirtieth, sixtieth and ninetieth day. Outcomes rather than activities: shipping small changes independently, owning a component, participating fully including on-call. It exists so both sides can tell how the ramp is going while there is still time to act on it.
Six to eight weeks to independent contribution for a mid-level engineer in a reasonably organised codebase. A quarter or more usually indicates the environment and the documentation are the problem rather than the hire, and that is worth establishing before drawing conclusions about the person.
The technical ramp is faster and the context ramp is not. A senior hire reaches independent contribution sooner and takes just as long to learn who decides what, which commitments already exist, and why the obvious improvement was rejected twice before. Senior plans should weight context over code.
Accounts and access provisioned before they arrive, a working local environment inside the morning, a named buddy with time booked, and a small real change identified. A first commit on day one is a reasonable target and a good diagnostic when it is not achievable.
The last person to go through it. Each new joiner updates the setup and the plan as they use it, which is the only mechanism that keeps documentation accurate — it is being read by someone who cannot yet route around the errors.

Sources

Page reviewed