A new hire onboarding checklist is the ordered list of accounts, links, documents, hardware, and people a new employee needs to become productive — sequenced across four phases: before day one, day one, week one, and the 30/60/90-day arc. The strongest checklists live in one shared place every new hire can reach, not a folder nobody finishes.
Onboarding fails in predictable ways: the laptop arrives late, two accounts are missing, the new hire spends week one asking where things live, and the 30-page handbook gets skimmed once. A checklist fixes the first three. Packaging it behind a single slug — b/onboarding — fixes the fourth. This playbook is the checklist, phase by phase, plus the specific links, docs, and people to put on it.
What goes on a new hire onboarding checklist?
Every good checklist covers the same five categories. Miss one and the new hire feels it on day two. Before you write a single line item, make sure each of these has an owner and a due date:
- Accounts & access. Email, SSO, Slack, the code host, the design tool, the HR portal, the password manager — the things that block work if they are missing.
- Hardware & environment. Laptop, monitor, peripherals, dev environment, VPN, and whatever physical or remote setup the role needs.
- Links & documents. The wiki, the runbooks, the roadmap, the org chart, the handbook — the destinations people open every week.
- People. Manager, onboarding buddy, skip-level, the team they sit with, and the cross-functional partners they will work with first.
- Milestones. First commit, first standup, first customer call, first review — the concrete moments that tell everyone onboarding is working.
Before day one: the pre-boarding checklist
Pre-boarding is the difference between a new hire who ships in week one and one who spends it waiting on IT. Everything here should be done before they log in — most of it owned by IT, the hiring manager, and the buddy. Copy this list:
- Order the laptop and peripherals with enough lead time to arrive a few days early.
- Create accounts: email, SSO / identity provider, Slack, the code host, the design tool, the HR and payroll portal.
- Add the new hire to the right groups, channels, and calendars, and to the on-call rotation (muted until they are ready).
- Assign an onboarding buddy and a manager, and put both 1:1s on the calendar before day one.
- Write a short, role-specific first-week plan: what to read, who to meet, what to ship.
- Record or update a two-minute welcome
b/loom-introfrom the manager — the team, the stack, the rhythm. - Build (or duplicate) the onboarding board and reserve the slug —
b/onboardingorb/onboarding-engper role. - Send a warm welcome email the week before: start time, first-day logistics, and the one slug to open.
b/onboarding — instead of six attachments. It resolves the same way from a browser, Raycast, or Spotlight, and it is the only thing they need to remember on a nervous first morning. Everything else hangs off that one board.Day one: the first-day checklist
Day one is about access and orientation, not output. The goal is a new hire who can log in to everything, knows who their people are, and has shipped one tiny thing — a profile, a comment, a one-line PR. Keep it light:
- Log in to every account and confirm access; flag anything missing to IT immediately.
- Set up the laptop: password manager, VPN, two-factor, and the baseline dev or design environment.
- Watch the welcome Loom and skim — not memorise — the handbook and the team page.
- Meet the manager (expectations and the first-week plan) and the buddy (the day-to-day questions).
- Learn the ten slugs that matter:
b/wiki,b/repo,b/oncall,b/runbook,b/dash,b/roadmap, and the rest of the role set. - Install the
b/resolver so slugs work from the address bar. - Ship one trivial thing: update the profile, post in the team channel, open a typo-fix PR.
- End the day with the buddy: what was confusing, what is blocked, what is next.
Week one: the first-week checklist
By the end of week one a new hire should have done real, if small, work and met the people they depend on. This is where the muscle memory forms — the slugs they typed on day one start firing without thought. A reasonable week-one set:
- Ship a first real contribution: a merged PR, a design review, a published doc, a handled ticket.
- Attend the first standup, planning, and retro — and say something in each.
- Read the core runbooks and the architecture or process overview for the team.
- Have 1:1s with the immediate team and the first cross-functional partner.
- Shadow one real piece of work end to end: a deploy, a support call, a launch.
- Confirm payroll, benefits, and equipment paperwork is fully closed out.
- Review the first-week plan with the manager and set the first 30-day goal.
The 30/60/90-day arc
The first day and week are logistics; the 30/60/90-day arc is about ramp. It sets explicit, role-appropriate expectations for the first three months so neither the new hire nor the manager is guessing. Treat it as a living agreement, reviewed at each mark — not a form filed once:
| Milestone | The new hire’s focus | What “on track” looks like |
|---|---|---|
| 30 days | Learn | Onboarded, shipping small changes independently, knows who owns what and where things live. |
| 60 days | Contribute | Owning a project or area, needing less hand-holding, giving feedback in reviews. |
| 90 days | Own | Fully ramped on core work, trusted with on-call or customer-facing tasks, proposing improvements. |
Keep the arc on the same surface as the day-one checklist. When the 30/60/90 review lives at the same slug the new hire opened on their first morning, the whole onboarding story — what they were handed, what they shipped, how the ramp went — sits in one place for the manager to scroll.
How do you package it into one shared board?
A checklist scattered across a Notion folder, a Slack thread, and an IT ticket is three places to lose it. The pattern that holds up is to put the whole thing behind one memorable shortcut. In BookSlash that means a board — a multi-tool canvas — sitting behind a single slug, b/onboarding.
The slug is a go link: a short, team-owned name that resolves from the address bar, Raycast, or Spotlight in well under 50ms. The board behind it holds the live pieces a flat doc cannot — the welcome Loom embedded and playing, a tasks node the new hire actually owns and checks off, a mind map of services that links each node to its runbook, and the buddy’s calendar to book the first 1:1. One URL, everything attached:
b/onboarding→ the board itself, the one link in the welcome email.b/wiki,b/repo,b/oncall,b/runbook→ the day-one slug set, pinned on the board.b/loom-intro→ the manager’s welcome video, embedded live.b/calendar-buddy→ book the first 1:1 without a Slack DM.
Build one board per role and duplicate it per hire — change the assignee, keep the structure. Because slugs are workspace-owned, the high-value names stay reserved, the audit log records who completed what, and nothing vanishes when the person who made the board leaves. The full pattern, with a node-by-node template, is on the onboarding use case.
Common onboarding-checklist mistakes
A few failure modes show up again and again. Most are cheap to avoid once you have seen them:
- Front-loading everything onto day one. Access and orientation belong on day one; real output belongs in week one. Cramming both overwhelms the new hire and guarantees something gets skipped.
- No single owner. “The team” onboarding someone means no one does. Name an owner for each phase — IT, manager, buddy.
- A static doc nobody updates. If the checklist is a copy-pasted page, it rots. Keep it on a board the team actually reuses, so fixing it once fixes it for the next hire.
- Stopping at week one. Onboarding is a quarter, not a week. Without the 30/60/90 arc, no one notices a slow ramp until it is a problem.
- Dead links. Hard-coded URLs break the week a dashboard moves. Slugs let you repoint once and every checklist stays correct.
Start small: write the four phase lists above, name an owner for each, and put them behind one slug your next hire opens on their first morning. If you are new to the shortcut idea, the go links guide covers how slugs resolve, and the onboarding use case shows the finished board. One b/onboarding beats six attachments every time.