People ops · 3 min read
Onboarding
Getting a new person productive is our job, not theirs. What we owe someone in their first weeks, and how we know it worked.
Your first week is written for the person arriving. This page is the other side of it: how we, the company, run onboarding, and what we hold ourselves to so that arriving here is smooth instead of a scavenger hunt. The short version is that onboarding is our responsibility, not the newcomer's. If someone's blocked, confused, or waiting on access in week one, that's a bug in our process, and the person best placed to catch it happens to be them.
Ready before they arrive
The fastest way to waste someone's first day is to spend it chasing accounts. So the work starts before they show up: the hardware, the logins, the GitHub org and Discord access, and a first task waiting for them are all sorted in advance. Day one should be about meeting people and getting oriented, not filing IT requests. When something is missing anyway, and sometimes it will be, fixing it fast is the priority, not an apology.
Everyone gets a first friend
New people don't know what they don't know, and rationing their questions to look competent is exactly the wrong instinct to encourage. So everyone gets a buddy: one named person whose explicit job is to be interruptible. Not their manager, not a formal mentor with a curriculum, just someone friendly to ask the "obvious" things without spending social capital each time. It's the cheapest, highest-leverage thing we do for a new hire.
The onboarding bar
A new person should be able to get an answer to almost anything within minutes, and ship something real within their first week. If either of those is hard, we fix the on-ramp, not the person.
The shape of the first months
We don't run a rigid checklist, but there's a rough arc, held loosely, that tells us onboarding is working:
- First week: oriented and shipping. Set up, introduced, and through the whole pipeline once with one small real change. The point isn't the change; it's proof the path from idea to production is clear.
- First month: contributing without a spotter. Picking up normal work, knowing where things live, asking sharper questions. Still supported, no longer shadowed.
- First quarter: owning something. A real piece of the product is theirs, end to end, in the feature ownership sense.
These are a check on us, not a test the newcomer passes or fails. If someone's behind the arc, the first question is what we didn't give them, not what's wrong with them.
The manager stays close early
Onboarding is the one time we lean toward more contact, not less. Managers check in frequently in the first weeks, through regular one-on-ones, so a small problem, a missing access, a misread expectation, a quiet struggle, gets caught while it's still small. That closeness tapers as someone finds their feet; it isn't how we manage forever, just how we start.
It never fully ends, and that's useful
There's no day someone is declared "onboarded." People keep learning the place for months, and a new hire sees the rough edges the rest of us have gone blind to. So we ask them to write down what confused them and fix it or flag it, because an unclear setup doc or a stale handbook page is a real bug. Improving the on-ramp for the next person is some of the most valuable work a new person does, precisely because they're the last person who'll ever see it with fresh eyes.