Onboarding that pays back in 30 days

How long it takes a new engineer to ship something real is a measurement of your environment, not of them.

That's the reframe worth holding, because it changes what you do about a slow number. If onboarding takes six weeks, the instinct is to write a better onboarding document. The actual cause is usually that your build takes forty minutes, your local environment requires three undocumented credentials, and the person who knows how the auth service works is on holiday. A new hire is just the only person who experiences all of that in a single week, with fresh eyes, before they learn to stop noticing.

Which makes every new hire a free audit, and one you can only run once per person.

Ship on day one

The target is a change in production on the first day. Small, real, theirs. A copy fix, a log line, a genuine one-line bug.

The point isn't the change. It's that shipping on day one requires the entire path to work: accounts exist, the repo clones, the build runs, the tests pass locally, someone reviews within the hour, and the deploy pipeline puts it in front of customers without a release train. If any link is broken, day one fails, and you've found the broken link on the cheapest possible day.

Most companies can't do this and the reasons are always specific and always fixable. Access takes three days because it needs a ticket to a team in another timezone. The onboarding doc was accurate in March. Nobody has permission to grant permission.

Fix those and you haven't just improved onboarding. You've shortened the path for everyone, every day, because every one of those obstacles is also being paid by the people who've learned to route around them.

If day one is genuinely impossible for you (regulated deploys, hardware, a release process with a legal step), then set the target at day three and be precise about which constraint is real. The number matters less than refusing to let it be "a few weeks, it varies."

The buddy, and what the role is actually for

Assign a specific person, not the team. "Ask anyone" means asking nobody, because a new person will not interrupt a stranger who looks busy, and everyone looks busy.

The buddy's job is not to teach the codebase. It's to be the person whose time the new hire is explicitly allowed to waste. That permission is the entire value. Every new engineer has a running list of questions they think are too stupid to ask, and the cost of not asking them is measured in days.

Make the allocation real: some of the buddy's own work comes off the plate for the first two weeks. A buddy who's still fully loaded will be helpful in a way that visibly costs them something, and the new person will notice and stop asking.

Pick someone who joined in the last year, if you have one. They still remember what was confusing, which the four-year veteran genuinely cannot.

Thirty, sixty, ninety, without the filler

The standard 30/60/90 is a corporate artefact that mostly reassures the manager. A useful version has one honest goal per stage and nothing else in it.

By thirty days: shipped several real changes, has been on call at least once with someone alongside them, and can draw the system on a whiteboard well enough to be wrong in interesting ways. Knows who to ask about what. Doesn't know the domain yet, and shouldn't be expected to.

By sixty: owns something. A service, a surface, a recurring responsibility. Small is fine. The transition from "doing assigned tickets" to "this is mine" is the one that makes people feel like they work here, and it's the one most commonly delayed by managers who are waiting for full confidence. Don't wait. Ownership is how the confidence gets built.

By ninety: has disagreed with something and been listened to, and has taught someone else something. Both of those are the actual finish line, because they're the point at which the person has stopped being a recipient of the organisation and started being part of it.

Notice what's missing: any measure of output volume. A new engineer's velocity in month one is noise, and setting a target for it teaches them to pick safe work.

The audit you get for free

Every new hire has a two-week window where they can see your organisation clearly, and then it closes permanently. Use it.

Ask them to keep a running document from day one. Everything confusing, everything that took longer than it should have, every doc that was wrong, every moment they thought "surely this isn't how it works." No filtering, no diplomacy. Tell them explicitly that this is a job you're giving them and that you'll read it.

Then at the end of week two, sit down and go through it, and fix at least three things that week, visibly. That last part is what makes the next new hire's document honest. If the first person's list disappeared into a backlog, everyone finds out, and the exercise becomes a polite fiction within two hires.

The fixes compound in a way that's easy to underrate. Each one is small. There are eleven of them per hire, and the same eleven were being paid, silently, by everybody already there.

What pairing costs you, and why it's still worth it

Three things make a fast first change possible: pairing, good runbooks, and an environment where changing something is safe. Pairing, pairing, pairing, if I'm being honest about the ordering.

Notice that the third one isn't a people property at all. Time to first meaningful change is gated by how frightened everyone is of changing anything, and that's set by your pipeline: how fast a build runs, whether a mistake is reversible, how long a rollback takes. Onboarding speed is a deploy-safety metric wearing a people costume, which is why teams with genuinely good CI tend to have good onboarding without having thought very hard about onboarding.

Pairing does the most work of the three, and part of what it does is cover for the other two. Sit a new person beside someone who knows the system and every gap in your documentation gets filled in real time, by a human, for nothing.

That's the right trade, and it's also why the audit above matters more than it looks, because pairing quietly disables the diagnostic. Your onboarding is fast, your docs are wrong, and nobody finds out, because the fix arrives conversationally and never gets written down.

There's a version of the test that can't be covered for, and it turned up recently without anyone asking for it. An agent can't pair. Point one at your codebase and it gets exactly the written context that actually exists, with nobody sitting beside it to explain what the file left out. Whatever it gets wrong is a direct readout of what your documentation is missing, and it's the same signal a stale context file gives you: degraded output whose cause is upstream of the model.

The part that isn't technical

The technical path is the easy half to fix. The half people get wrong is the social one, and remote makes it much harder.

A new person needs to know, quickly: who decides things, who to go to when stuck, what the unwritten rules are, and whether it's normal here to say you don't understand something. None of that is in a document, and all of it is learned by watching, which is precisely what a remote new hire can't do.

The cheap intervention is deliberate: five scheduled fifteen-minute conversations in the first fortnight, with people outside their immediate team, with no agenda beyond "what do you do and what should I know about it." Feels like overhead. It's the difference between someone who has a network in month two and someone who is still asking their manager everything in month six.

What to measure

One number, tracked over time, and it's not satisfaction: days from start date to first change in production, and days to first change they'd call meaningful.

Ask each new hire for both, in their fifth week. Write it down. If the number is going up over successive hires, something in your environment is silting and this is the earliest place it will ever show.