The day 1 onboarding checklist we finally trust

Our first attempt at onboarding was a Google Doc that nobody updated. Our second was a Notion database with fourteen owners and no owner. This is the third version, which has run through nine hires without a rewrite, and which our last four joiners have said was the first day at a job that felt planned.

The rule we work backwards from: nobody sits idle. Not the new hire, not the buddy, not the manager. Every hour on day 1 has a defined output, and we can point at the output the next morning.

The twelve items

We track this as a Linear project cloned from a template. Each item is a ticket assigned to the person responsible, with a due time in London hours. If a ticket slips, it pages the hiring manager in Slack. Nothing here is aspirational; every item has failed at least once, which is why it made the list.

1. Laptop imaged and on the desk by 08:30. IT owns this. If shipping is late, we send a loaner from the office by courier the night before.
2. Accounts provisioned in Okta. Google, GitHub, Linear, Slack, Notion, Datadog, Figma, 1Password. Provisioned the Friday before, tested by IT with a throwaway login so we catch a missing SSO group before Monday.
3. Buddy assigned and confirmed. Named two weeks in advance, blocked on the calendar for the whole day, not a stretch assignment for someone already underwater.
4. Welcome standup at 09:15. Fifteen minutes with the immediate team. Names, what each person is shipping this sprint, one question the new hire wants answered.
5. Dev environment running by 11:00. We keep a bootstrap script in the main monorepo that clones, installs, seeds the database, and runs the test suite. If it fails on a fresh machine, that is a P1 for the platform team.
6. First PR opened by 14:00. Every team keeps a small backlog of tickets tagged good-first-issue. Copy tweaks, config renames, a missing test. The point is to touch the pipeline.
7. First commit merged by end of day. The buddy reviews, the CODEOWNERS bot approves, CI runs green, and it deploys through our normal path. No ceremony, no exemption from the release train.
8. Three intro coffees on the calendar. Not scheduled by the new hire. The manager picks three people outside the immediate team and books thirty minutes each across the first two weeks.
9. Engineering handbook read. Sixty pages in Notion. It covers how we branch, how we write RFCs, how we run incidents. We ask two questions about it at the retro.
10. Shadow the 15:30 standup for the sister team. We want new joiners to see how another team runs before their own becomes familiar.
11. Post in #intros. A short paragraph and a photo of something the person likes. Not a policy, but a norm every hire has followed for two years.
12. End of day retro with the buddy. Twenty minutes. What worked, what was confusing, what the new hire wants to change tomorrow. Written up in the Linear ticket and read by the manager the next morning.

Why the first commit matters

People argue this one with us. They say it puts pressure on the new hire, or that the commit is trivial and doesn’t prove anything. Both criticisms are fair, and both miss the point.

The first commit is not a test of the new hire. It is a test of us. If a fresh joiner cannot ship a one line change on day 1, we have broken something: the bootstrap script, the CODEOWNERS file, the CI pipeline, the deploy access, or the buddy’s calendar. When we started measuring this, we found that on average two of those five were broken for any given hire. Now it is closer to zero.

The first commit is a test of us, not of the new hire.

The commit itself is often a typo fix in the marketing site or a colour token in Figma renamed in code. What matters is that the person walked the full path, saw the review comments, watched CI go green, and got the Slack notification when their change went live in production.

What we cut

The first version of this list had twenty six items. We cut fourteen. The pattern for cutting was consistent, and worth naming.

• Anything that could wait until week two, waited until week two. Payroll paperwork, benefits enrollment, the security training module, the office tour with facilities. None of these help someone feel oriented on day 1.
• Anything that produced no artifact came off. A “meet the CTO” slot without a follow up was noise. The CTO now joins the Friday demo instead, which is a real meeting with a real output.
• Anything owned by more than one team came off. Shared ownership meant nobody chased it. Every remaining item has exactly one accountable owner, listed in the Linear ticket.

We run this checklist every Monday and most Tuesdays. Nine hires in, the pattern holds. The buddy is tired by 17:00, the new hire is tired by 17:30, and the manager has a written retro to read on Tuesday morning. Nobody sat idle.