Onboarding checklists tend to be either a wall of tasks nobody follows or three bullet points that assume everything else. This one is organised by when things happen and by whether a person is genuinely needed.
Before day one
Most onboarding failures are already baked in by the time someone starts.
- Provision access. Slack, email, calendar, and the tools they'll need in week one. Chat access first — it's usually the fastest to set up and it's where everything else can be coordinated from.
- Assign a buddy. Someone who isn't their manager, who they can ask obviously basic questions without feeling assessed. This is the highest-return item on the list and the one most often skipped.
- Write the first week's plan. Not a full ramp plan — just what they'll do on days one through five, so they aren't guessing.
- Tell the team. A short message with who's joining, what they'll be doing, and when to expect them. Costs nothing and prevents the awkward first-day introduction round.
- Queue the onboarding sequence so material starts arriving without anyone triggering it manually.
Day one
Keep it deliberately light. Almost nothing said on day one is retained.
- Introductions — manager, buddy, immediate team. In person or on a call, not in writing.
- Orientation module — what the company does, how teams are organised, who to ask about what. Short.
- A first small task. Something completable that day. Shipping anything, however trivial, does more for confidence than any amount of context.
- Do not cover policies, expenses, security, or systems detail. It won't land and you'll have to repeat it.
Days two to five
Tools and process, arriving just ahead of when they're needed.
- The systems they'll actually touch — one short module each, not a tour of everything the company uses.
- How work gets done — the specific rituals: standups, code review, ticket flow, how decisions get made.
- Where to find things — documentation, the wiki, which channels matter.
- Manager check-in at the end of week one. Ask what's confusing. The answer is always useful and rarely volunteered.
Week two
Policies, which is also where compliance obligations sit.
- Code of conduct, expenses, time off — each as a short module with a check at the end, so completion is recorded rather than assumed.
- Security awareness — this one usually has an audit requirement attached, so make sure the record is per-person and timestamped.
- Any role-specific compliance — handling customer data, regulated processes, whatever applies.
Weeks three and four
Depth, once there's enough context for it to mean something.
- Role-specific material that would have been noise in week one.
- Product or domain knowledge in whatever detail the role needs.
- A second manager check-in, this time about how the work itself is going rather than logistics.
- Ask for feedback on the onboarding. They're the only people who can see it clearly, and they'll never have this perspective again.
What to automate and what not to
Automate: access provisioning, the module sequence, assignment to new joiners, reminders, completion tracking.
Don't automate: introductions, the buddy relationship, manager check-ins, answering questions, deciding the first task. Automating the material is worth doing precisely because it frees attention for these.
Make it not depend on memory
The single change that makes a checklist actually run is assigning to everyone who joins from a date forward rather than enrolling people individually. Otherwise a busy month means someone silently gets nothing, and you find out months later.
Poplearn does this with /assign — target a channel or all future new hires, and the sequence runs whether or not anyone remembers. /courses new turns your existing onboarding doc into the modules, and /progress shows live completion by team.
Free under 20 seats, installs in about a minute.
