Employee Onboarding

For a long time, settling into a new job was treated as the new person's problem. Get shown to a desk on day one, sign the paperwork, and from there it was on you to ask and to learn. People who read a room quickly got up to speed quickly and people who didn't took longer, and the difference got explained as personality rather than as something the company had arranged.

The first week usually looked like this. The laptop isn't ready, so two days go by at a borrowed desk. The machine arrives on day three, but the permissions needed to set up a development environment don't, so there goes another day. You want to ask where the documentation lives, except the person next to you looks busy and you don't want to interrupt. A week in, your manager asks how you're settling in, and there's nothing to say except that it's going fine — even though almost nothing got done.

Three things made that arrangement stop working. First, hiring got expensive. Months go into writing the post, running interviews, and agreeing on terms, and if the person who came through all that leaves within three months, those months are simply gone. Second, the background knowledge required to work on a product grew. Reading the code doesn't tell you why the structure ended up this way; someone who was there has to tell you. Third, desks scattered. With remote and office work mixed together, the things people used to absorb by overhearing stopped being transmitted at all, and anything not asked about is never learned.

Put together, the three made it obvious that how the first three months go depends heavily on the company. When two people with identical experience join different companies and one is owning a feature by week three while the other is still reading documents in month two, the difference came from the two companies, not the two people.

So the work of settling in moved from the individual to something the company arranges in advance. What arrives on day one, who gets met in week one, what counts as done by the end of month one — all of it gets decided once instead of improvised per person. The goal is that the tenth person hired into a role gets the same preparation the first one did.

The People axis splits organizational work into nine branches following a person from arrival to exit, and employee onboarding is the second, settling in. Hiring owns everything up to the signed offer and the first day. From there, this owns getting an already-hired person to full speed. When the two are disconnected, companies lose people they went to a lot of trouble to find.

Five terms sit under employee onboarding, in four branches: when the process starts, what it uses to help, how to tell whether it's working, and what contractual clock runs alongside it.

Stage covers the question of when onboarding actually begins.

1. Preboarding — the stretch between a signed offer and the first morning, used to get the preparation done early. Order the hardware, create the accounts, send the first-week schedule and the documents worth reading, and collect the paperwork in advance. Crammed into day one, all of that consumes the day; moved earlier, the day goes to meeting people and looking at the product. It also does quieter work: when weeks pass between acceptance and the start date with no contact, some people drift back toward the offers they turned down.

Instruments cover what actually helps a new hire. One gives them a person, the other gives them a target.

1. Buddy system — pairing a new hire with an experienced colleague. Picking someone with no role in evaluating them is the whole trick, because the questions that matter most are the ones you can't take to a manager: is this channel the right place for this question, is it fine to skip that meeting. A typical arrangement is 30 minutes a week for the first month, with the buddy opening the conversation rather than waiting to be asked. The buddy needs to be told what the role involves, too. Assign the name and nothing else and it tends to end after one lunch.
2. 30-60-90 plan — a written statement of what should be true 30, 60, and 90 days in. The first 30 days are for learning: read the documents, meet the people, use the product. Days 30 to 60 are for taking small things on for real. By day 90 the person makes calls in their area without checking first. For a new engineer that might read as one small bug fixed and shipped by day 30, one feature owned by day 60, and reviewing other people's code by day 90. With the plan written down, "am I doing all right so far" has something to be answered against. The manager usually drafts it before the start date and adjusts it together with the new hire in week one. Handing the drafting to the new person produces goals set by someone who doesn't yet know the company, and they usually aim at things a first month can't hold.

Metrics cover how to tell whether any of this is working.

1. Ramp-up time — how long it takes a new hire to carry their own weight. Counting it requires a marker agreed on per role: the day an engineer's first change reaches production, the day a salesperson closes a first deal. Where the number differs between companies, the cause is usually preparation rather than talent. If engineers with the same experience take three days at one company and three weeks at another, the gap lives in documentation, permissions, and environment setup. Shortening the number for its own sake does loosen the marker, though. Make "first change shipped" the target and a one-line typo fix in week one starts counting.

Policy covers the contractual clock running over the same weeks.

1. Probation period — time set aside before employment is confirmed, written into the contract and usually three months. Employment protections still apply during it, and reaching the end of it does not let a company end the contract without grounds. Without agreed criteria and a set moment for sharing the result, three months pass with each side holding a different expectation. For the new hire the period is often a source of quiet anxiety, which a check-in halfway through mostly settles: nothing said in the final month comes as news.

The four branches interlock along a timeline. Preboarding takes the days before day one, the buddy and the plan fill the first 90, ramp-up time records the outcome as a number, and probation lays a contractual decision point over the same span. Drop any one and it shows. A plan with nobody to ask means the documents go unread; a buddy with no target means two people trade pleasantries for a month. Ramp-up time with none of the other three in place is just a number that confirms, quarter after quarter, that new hires take a long while to get going.

"Where are we on preboarding for next week's start? Just confirm the laptop and the accounts."

Checking whether anything that should have been finished before day one is still open.

"Ramp-up time went from six weeks to four this quarter."

New hires are reaching full speed sooner, which usually reads as better preparation rather than better hires.

"The onboarding docs haven't changed in six months. Last week's starter got stuck in three places."

The documentation has aged out of the current setup.

Pagedeck wrote this process down for the first time while hiring four engineers and a designer over six months. Before that, Theo sat next to each new arrival and walked them through everything over a day. By the fourth repetition, that habit had grown into a week of his time.

What Mia did first was not write a new document but ask the most recent hire where they got stuck. Three answers came back. The environment setup guide described a structure that was six months out of date. Nothing anywhere said which channel to ask which kind of question in. And for the first two weeks they had no idea what they were supposed to accomplish, so they spent it reading the room.

Each answer got one fix. The setup guide became something new hires edit themselves, on the logic that the person who hit the wall is the one who can keep the next person from hitting it. The channel guide went into the preboarding email. And the first-90-days plan became something managers write before the start date. Noa being able to open design files on her first afternoon was the result of those three moving earlier. Writing the documents took less than half a day. The slow part was finding out what was broken, and that answer had been inside the company all along — nobody had written those three things down until four previous hires were asked.

The most common misuse treats employee onboarding as a synonym for first-day orientation. That day — the company intro, the signatures, the desk — is the visible part, so the name sticks to it. But most of what happens on day one is administration, and the places new hires actually get stuck turn up in weeks two and three. Treat it as a one-day event and only that day gets prepared, with everything after it handed back to the individual. The result is a great first day followed by someone still lost a month later. Day one is closer to the day to give the least information rather than the most: ten introductions and six policy briefings in one sitting leave almost nothing behind.

The other common mistake is filing this under the people team. Contracts, accounts, and equipment come from there, so the rest looks like it should too. What a new hire actually needs, though, is to know what this team is working on and why, who to ask about what, and what to accomplish in the first month. None of those three are things a people team knows. What that team can prepare is the frame; filling it in belongs to the manager and colleagues on the team the person joined. Blur the split and you get accounts that all worked on day one next to someone who still doesn't know what they're supposed to be doing in week two.