The 30-60-90 onboarding programme, as a checklist you can steal
The 30-60-90 structure survives because it encodes one good idea: onboarding should be a sequence of competency gates, not a stretch of time served. Day 30 proves understanding, day 60 proves supervised doing, day 90 proves independent owning. Everything else — the decks, the walkthroughs, the checklists — exists to get people through those gates.
Most 30-60-90 plans fail not from bad intentions but from missing artefacts: the plan lives in a manager's head, the "checkpoint" is a vibe, and nobody can say what "ramped" means. What follows is the checklist version — concrete enough to steal, with the artefact you need to build at each stage.
Before day one
The strongest signal you can send a new hire arrives before they do. The pre-boarding checklist:
- Accounts, hardware, and system access requested at least a week out — day one spent waiting on IT tickets is the classic self-inflicted wound.
- A short welcome pack: who's who on the team, first-week schedule, what to prepare (usually: nothing — say so explicitly).
- A manager checklist with named owners: who does the systems walkthrough, who takes the first lunch, who is the designated question-answerer.
- The buddy assignment. Not a mentor, not the manager — a peer whose formal job is "ask me the questions you think are too stupid for your boss".
Week one: orientation, deliberately shallow
Week one has one goal: the new hire can navigate — the org, the tools, the vocabulary. It is not the week to transfer deep knowledge; retention for a firehose week is dismal, and everyone senses it except the people scheduling eight hours of back-to-back sessions.
The first-week deck is the anchor artefact. It needs exactly five things:
- What the organisation does and for whom, in plain language.
- How this team makes money or creates value — the one-diagram version.
- The people map: names, faces, what to ask each person about.
- The tools list, with links and who grants access.
- The 30-60-90 plan itself — show them the gates on day one, so the whole programme is legible.
This deck is also the artefact most likely to be stale, because it changes every quarter and lives in someone's personal drive. Give it an owner and a review date, or better, make it cheap enough to regenerate that staleness stops being the default. (This is a natural fit for generated, editable decks — the content brief barely changes; the artefact rebuilds in minutes.)
Days 1–30: learn, then prove understanding
The first month is structured input: systems walkthroughs, product or policy modules, shadowing sessions with a written "what to watch for" sheet so shadowing is observation with a rubric rather than sitting nearby. Put the must-know modules in the LMS with completion tracking — onboarding is precisely the case where you want an auditable record that every hire saw the security, conduct, and data-handling material.
The day-30 gate
The checkpoint is a structured conversation plus a light assessment — not a performance review. What it should establish:
- Can they explain the team's purpose and their role in it, unprompted?
- Required modules complete, knowledge checks passed (an LMS report, not a memory).
- Can they perform the guided version of one core task, with someone watching?
- Two-way feedback: what's confusing, what's missing from the programme itself.
Days 31–60: do, with support
Month two inverts the ratio: mostly real work, deliberately scoped, with fast feedback. The pattern that works is real but bounded— an actual deliverable with a reviewer and a deadline, chosen so failure is affordable. Avoid the two classic month-two mistakes: keeping the hire on toy exercises (they notice, and it stalls trust), or dropping the support structure entirely because "they're through orientation".
The day-60 gate
- At least one real deliverable shipped and reviewed.
- Core-task quality at "needs light review", no longer "needs supervision".
- For tool-heavy roles, a practical assessment rather than a quiz — if the role lives in spreadsheets, a real workbook task with rubric grading tells you what a multiple-choice test can't.
Days 61–90: own it, then make it official
Month three is independence with visibility: the hire owns a slice of work end-to-end, and the support structure goes from scheduled to on-demand. The day-90 review is the formal close of onboarding, and it should produce a written outcome: competencies confirmed (with the evidence — assessment results, shipped work, completed modules), gaps carried into a normal development plan, and the hire's own critique of the programme, captured while the experience is fresh. That critique is your improvement loop; new hires see the holes in your onboarding more clearly than anyone who's been around long enough to route around them.
Where these programmes actually fail
- The week-one content dump.Everything "important" crammed into days 1–5, then silence for eleven weeks. Spread it out; retention follows spacing.
- Gates without pass conditions.Checkpoints happen, everyone "is doing great", and at month six someone asks why the hire still can't run the core process alone.
- The absent manager. A buddy and an LMS cannot substitute for weekly manager one-to-ones in the first 90 days. Nothing else in this article works without that.
- No measurement.If you can't say how long ramp takes now, you can't show the programme improved it. Time-to-first-deliverable and gate pass rates are enough to start — more in our measurement field note.
The artefact list
Steal the structure by building these seven things: a pre-boarding checklist, a first-week deck, a systems-walkthrough module (LMS-tracked), a shadowing rubric, three gate scorecards with written pass conditions, one practical assessment per core skill, and a day-90 review template. That's a realistic one-quarter build for a small L&D team — and considerably less if the decks, modules, and assessments are generated from briefs rather than built by hand. If you want to see how fast the first-week deck comes together, try it free — no account needed.