Day one of the plan was perfect. Tasks in queues, invites on calendars, a welcome email people replied to with emoji.
It's day 23 now. The manager's 1:1 quietly stopped recurring after week 3. The day-30 check-in got declined, "conflict, will rebook," and never was. The first real task is still sitting unassigned, and the hire has started inventing their own work, which is either great or terrible and you don't know which.
You'll find out about all of this around day 41, by accident, in a hallway conversation.
Nobody decided to stop onboarding this person. It just went quiet. Plans don't fail at the start, they fail in the middle, when everyone's attention has moved to the next fire.
Now think about how you'd handle the middle if you had someone to hand it to. They'd walk the board every Monday morning. What's overdue and whose is it. What dropped off a calendar and didn't come back. Who's in week one with no laptop and no first task. And they'd come to you with a short list and three nudge messages already written, waiting for your go.
That Monday walk is what this lesson builds. Not the someone, the walk. The plan from Creating a plan for a new hire says what should be true on every date. The tracker and the calendar say what is true. Comparing the two is exactly the kind of dull, careful, weekly work you should never do by hand again.
And the same rhythm carries the real HR work of the middle: the check-in briefs, the surveys, the 90-day review. That's the second half of this lesson.
Before you start
Three things need to exist:
→ At least one live plan from Creating a plan for a new hire. A hire with a board in your tracker and invites on calendars. The watcher compares reality against the plan, so there has to be a plan.→ The Onboarding plans project, with its instructions and the one-chat-per-hire convention. The watcher runs from here and leans on those chats.→ Scheduled tasks, from From one-off prompts to autopilot. The clock. If you set up the Monday people brief back then, you already know the shape: a written task, on a clock, that starts without you.
What you'll have at the end
→ The watcher. A scheduled task, Monday mornings, that reads every open hire's board and calendar, compares them against the plan, and writes one report: what's overdue by owner, what dropped off calendars, who's got nobody chasing them.→ Chase drafts. Every item in the report arrives with the nudge already written, addressed to the right person. You review and send.→ The readiness check. The same watcher flags any hire inside two weeks of starting whose pre-start tasks aren't done. The laptop gets caught on day minus 7, not day 1.→ Running statistics. One file that accumulates a dated row every week: active onboardings, tasks on time versus late, who's late most, check-ins held versus missed. The trend line nobody has ever had for onboarding.→ Check-in briefs. Before every 30, 60 and 90 day conversation, an agenda built from the plan, the tracker, and the last check-in's notes.→ Surveys that run themselves. Sent at the right week, summarized into the hire's chat, flagged when an answer needs a human.→ The 90-day review pack, everything the manager's decision needs and no opinion about it.→ The improver. A second scheduled task, Fridays, that reads the surveys, the check-in notes and the week's reports across all hires, and proposes up to three concrete edits to your process docs. Proposals only, never silent changes.
One line for the chapter: the plan holds what should happen, the watcher notices what didn't, and you stay the only one who sends.
The watcher
Open the Onboarding plans project and set it up in one move. Paste this, then tell Claude to run it as a scheduled task every Monday at 8:30:
Every Monday, run the onboarding watch.
1. Read processes/onboarding.md in my Claude-HR folder first. Its
tools section tells you where everything lives: which tracker
holds the per-hire boards, which calendar we book on, and
whether each owner is reached in Slack or by email. Work from
what it says, never from assumptions. If it names a tool you
can't reach, say so in the report instead of skipping it
silently.
2. Find every hire with an open onboarding: started in the last 90
days, or starting in the next 30. Their plans are the chats in
this project and their boards in the tracker.
3. For each hire, compare the plan against reality:
- overdue tasks: what, whose, how many days late
- calendar drift: check-ins declined or cancelled and never
rebooked, recurring 1:1s that stopped, intro meetings that
never happened
- readiness: anyone starting within two weeks with pre-start
tasks not done: laptop, accounts, first task unassigned
4. Write one report across all hires: overdue by owner, calendar
drift, readiness gaps, and anything nobody is chasing. Worst
first, three lines per item, initials only.
5. Draft every reminder in the tool that reaches its owner, per the
process doc: a Slack message, or an email in Gmail or Outlook.
In my voice, ready to send. Send nothing. Drafts only.
6. Update OUTPUTS/onboarding-stats.md: append one dated row with
active onboardings, tasks completed on time vs late this week,
late tasks by owner, check-ins held vs missed, and any hire
fully ready before day 1. Append, never rewrite past rows.
That's the whole machine, and notice what its first step is: reading the process doc. The watcher doesn't hardcode your tools, it learns them from processes/onboarding.md every Monday. Switch trackers next year, update one section of one doc, and the watcher follows. That's the pointers-not-copies rule paying rent.
The rest runs on what Creating a plan for a new hire built. The watcher can only say "late, and it's IT's" because the plan said "due May 22, owner: IT."
Two of its habits are worth naming, because they're where the value hides.
The calendar is the early-warning system. A declined check-in that never got rebooked is the earliest signal onboarding produces that something's drifting, and in most companies literally nobody is watching for it. The tracker tells you about late tasks. The calendar tells you about fading attention, which is the thing that actually kills onboarding in month two.
The readiness check buys you the week that matters. Every pre-start failure, the laptop, the accounts, the unbooked 1:1s, is invisible until day one and obvious on day one. Catching it at day minus 7 costs a nudge. Catching it at day 1 costs the hire's first impression of your company.
Chasing means drafts
The report arrives with the nudges written. A Slack message to the manager about the 1:1s. An email to IT about the laptop. Short, specific, in your voice.
You read them, maybe soften one, and send. Thirty seconds for the whole batch.
Why not let them send automatically? Because a nudge from you is social pressure, and social pressure is the entire mechanism. People answer you. They ignore automated pings within a week of meeting them, and then the pings train everyone to ignore the system that sent them.
So the rule from Module 1 doesn't bend here, even though this is the lesson where bending it would feel most convenient: Claude drafts, you send. The chasing is automated. The relationship isn't.
The numbers that accumulate
Step 6 of the watcher is quiet, and it might be the most valuable line in the prompt.
Every Monday, one dated row lands in OUTPUTS/onboarding-stats.md: how many onboardings are running, what got done on time versus late, who was late, which check-ins actually happened, whether the last hire was ready before day 1.
One row is trivia. Twelve rows are a trend, and a trend is a different kind of fact. "IT has been the late column in five of the last six weeks" is not a nudge anymore, it's a process problem with evidence attached. "Every check-in this quarter happened" is the sentence you get to say when leadership asks whether onboarding is under control, and until now nobody at your size has ever had it.
The stats file also feeds the retro at the end of this lesson, and later, the module's reporting. You're not building a dashboard. You're letting one accumulate as a side effect of the watching.
The honest limit
Say this plainly, because the whole lesson rests on it: Claude sees what the connectors see. If nobody ticks the boxes in the tracker, the report is fiction with a timestamp.
Someone still has to mark tasks done. The weekly report is actually what makes that happen, because a task that stays unticked gets its owner named every Monday until it moves. GitLab runs its onboarding on exactly this rule: every box gets ticked or marked not-applicable, and an open checklist is somebody's problem by name.
But the dependency is real, and pretending otherwise is how trust in the whole system dies. The watcher doesn't replace the discipline of updating the tracker. It's what makes that discipline worth five seconds of everyone's time.
The work between the reports
Monitoring is half the lesson. The other half is the HR work the middle of onboarding actually contains, and it runs on the same rhythm.
Check-in briefs. The 30, 60 and 90 day conversations belong to the manager, but the preparation is yours, and it's exactly the kind of assembly Claude is for. Before each one: "Build the brief for the day-30 check-in. The plan's goals for this stretch, what the tracker says got done, the survey signal, and what the last check-in's notes promised." The manager walks in prepared instead of improvising, which is the difference between a check-in and a coffee.
Surveys. Draft the questions once, two short sets: week 2, how's the setup and the start, and week 6, how's the work and the team. A scheduled task sends each at its moment and summarizes what comes back into the hire's chat.
Two rules for the analysis, both firm. Patterns and quotes, never scores: a survey summary that rates the new hire has changed what the survey is, and the hire will feel it in the next one. And the survey measures the process, not the person. "The environment docs were stale" is the finding. "Hire seems negative" is not a finding, it's a misuse.
The day-30 conversation is also where you harvest what Buffer calls beginner's mind. A new hire sees your broken steps for exactly one month, then goes native. Ask what confused them while it still confuses them.
The 90-day review. The pack Claude builds for the manager: goals from the 30/60/90 and what happened against each, the check-in notes, the survey signal, the shipped work. Everything the decision needs, and no opinion about it. This is Module 1's line at maximum load, so it's worth saying verbatim: automate the prep, not the decision. Claude assembles the record. The manager judges. That boundary is not efficiency, it's what keeps the review defensible.
The improver
The watcher chases this week's problems. The improver reads them as evidence about the process, and it's the second timer you'll set: Fridays, after a week of watching, surveys and check-ins has accumulated.
Every Friday, run the onboarding improvement review.
1. Read, for every hire active in the last quarter:
- their survey answers and summaries
- their check-in notes from the 30/60/90 conversations
- the watcher reports and OUTPUTS/onboarding-stats.md
- logs/feedback-log.md
- processes/onboarding.md and the department docs
2. Look for patterns, not incidents:
- a step late for two or more hires, or two or more weeks
running
- the same complaint or question from more than one hire, in
surveys or check-ins
- a 30/60/90 goal that slips for the same reason across hires
- gaps between what the docs promise and what check-ins report
actually happened
- [SUGGESTED] and [GUESS] lines in the docs still unresolved
3. Propose at most three improvements, highest impact first. For
each: the evidence (counts, quotes with initials, dates), the
exact edit (which document, which section, proposed wording),
and what it should fix.
4. Never edit the documents yourself. Proposals only. I accept,
adjust, or ignore.
5. Log what you proposed and what I decided in
logs/feedback-log.md.
You've seen this shape before: it's the weekly context review from How to organize context files, specialized for one process. Same discipline too, and it's the discipline that makes the whole thing trustworthy: the improver proposes exact wording and never touches the files. A process doc that edits itself is a process nobody agreed to.
Three design choices carry the weight. Patterns, not incidents: one late laptop is the watcher's job, a laptop late for the third consecutive hire is the improver's, and the two tasks read the same evidence to do opposite things with it. At most three proposals: ten suggestions every Friday is noise you'll stop reading by November, three is a review you'll actually do over coffee, and the scarcity forces the ranking. Evidence attached: "move hardware to 14 days before start, because it missed the 10-day mark on the last three hires" is a decision you can make in ten seconds, in either direction.
The Friday ritual
The proposals arrive. You read three short blocks. For each: accept, adjust, or ignore.
Accept, and you tell Claude to apply the edit. Adjust, and you change the wording first. Ignore, and you say why in one line, because the why gets logged and stops the same proposal returning every week.
One ownership rule: a proposal that touches a department doc goes to that department's manager for the yes. They wrote it in Documenting the onboarding process, they own it, and an HR-approved edit to engineering's onboarding is how department docs quietly die. Forward the block, get the nod, apply.
The late laptop becomes a longer lead time in the doc. The meeting nobody understood gets a why or gets cut. The question three hires asked becomes a line in the first-week doc. That's the compounding move of the whole module: the docs generate the plan, the plan gets watched, and what the watching finds flows back into the docs. Hire thirteen inherits everything hire twelve suffered.
And once a quarter, same evidence, longer lens: "Read the full stats history, all survey answers and check-in notes from the last quarter. Write me one page: what improved, what's still recurring, and the three numbers I should show leadership." Early attrition is the one onboarding number CEOs ask about, and the honest answer to "is onboarding under control?" is now a page of evidence instead of a feeling.
One thing left, and it's the gap you've probably already noticed: all of this runs through email, calendars and the tracker. But that's not where your company talks. The questions, the welcomes, the "who do I ask about expenses," they all happen in Slack. Onboarding in Slack moves onboarding there: one channel per hire, the plan pinned as a list everyone can tick, and the reminding delivered where it actually gets read.
The middle of onboarding just got a keeper. Time to give it a place to live.
Up next
→ Onboarding in Slack. One channel per hire, the plan as a pinned list, and reminders where they get read.