Onboarding that works

Same developer, two different outcomes

A few months ago we talked to two companies that hired developers with almost identical profiles in the same week. Same level, similar stack, comparable experience.
At one company, the new hire was shipping code to production within two weeks. At the other, three months in, they were still asking where the API docs were and who owned payments.
The difference wasn't the developer. It was the process meant to bring them into the team.

Why this costs more than it looks like

A new hire isn't a cost that disappears once the contract is signed. It's a cost that grows every single day they aren't creating value. The salary keeps running, senior engineers keep spending time explaining things, and the product doesn't move forward.
There's a quieter second cost. New hires decide whether they're staying for the long run in exactly those first few weeks. If those weeks feel like wandering in the dark, some of them start looking elsewhere before anyone gets to see what they're capable of.

New hires decide whether they're staying in the first few weeks, not after the first year.

You don't see this effect right away. You see it in turnover, months later, when it's hard to trace an exit back to what the first month actually looked like.

What teams that get it right actually do

• Day one is planned, not improvised
  Access, accounts, and the dev environment work before the new hire sits down. No waiting half a day for someone to find time to grant repo access.
• Code ships in week one, not month one
  Teams that ramp up fast keep a ready list of small, well described, low risk starter tasks. A first pull request in week one gives something no onboarding deck can: the feeling of being capable and useful.
• There's one clearly assigned person, not "the whole team
  "Ask anyone" in practice means nobody feels responsible. One buddy with real time blocked on their calendar is the difference between "someone will answer eventually" and "I know exactly who to go to right now."
• Documentation is current, not just extensive
  Docs describing a system from a year ago are worse than no docs at all, because they create false confidence. Strong teams treat documentation like code: someone owns it, outdated sections get deleted.
• Feedback goes both ways, and fast
  A short, informal "how's it going" check-in every week catches problems before they grow. Waiting for the first performance review at month three means fixing something that already hurt.

What it actually costs if you skip this

Hard to put an exact number on it, but the direction is clear. If a senior engineer spends an hour a day explaining the same things for three months instead of three weeks, that's dozens of hours of your most expensive person's time not going into the product.
Then there's turnover cost on top. Recruiting, ramping, losing the knowledge, recruiting again — that's always more expensive than fixing the process that made someone leave in their first few months.
A well designed onboarding process isn't an investment in a nice welcome gesture. It's an operational investment that pays for itself in weeks, not years.

What a good onboarding plan should include

A good onboarding plan isn't a list of trainings to sit through. It's a set of concrete, time-boxed checkpoints: day one with a working environment, week one with a first pull request, month one with an independent feature, month two with a first supported on-call shift.
Every checkpoint needs an owner and a way to verify it actually happened. Without that, onboarding turns into a wish list nobody has time to execute.

One sentence to close

Your team probably already knows exactly where new hires get lost, nobody has just sat down to write it down and fix it yet.