Onboarding

/onboarding -- New-Hire Ramp-Up

Fast-path companion to Pillar 5 (Optimize the Team). Builds a ramp-up plan for a specific new hire, without running a full /team health assessment. The book's guidance: a roster of A-players needs the direction, tools, and peer support to do their best work -- onboarding is where that support either starts or doesn't.

When to invoke

• A new hire joins, or is about to join, a team or project
• A recent hire (first 90 days) is struggling and it's unclear whether it's a skill gap or a setup gap
• Standing up a new team from scratch, where everyone is effectively "new hire day one"

What it checks

1. Direction -- does the new hire have a written first-30/60/90-day plan, or are they expected to figure out priorities themselves?
2. Buddy / mentor -- is there a specific person (not the tech lead by default -- that overloads the one person everyone already depends on) responsible for day-to-day questions?
3. Tooling & access -- what blocks a first commit today: missing repo access, missing local-env docs, missing credentials? (A slow first-commit time is itself a Speed-adjacent signal worth naming.)
4. Early signal -- for a hire already a few weeks in, what does their question pattern show (routing everything through one person is a Storming-stage red flag per /team)?

Inputs

• Role & context -- what the new hire was hired to do, and their starting experience level with this stack
• Existing onboarding material -- a README, wiki page, or checklist if one exists; its absence is itself the first finding
• Direct signal, if already ramping -- 1:1 notes, or who they've been asking questions to, as a proxy for whether a buddy relationship actually exists vs. exists on paper

Example output

Onboarding plan -- new backend engineer, Atlas team, starts 2026-08-03

Direction: No written 30/60/90 plan exists yet. Recommend: Week 1 -- ship one small bug fix end-to-end; Week 2-4 -- own one small feature with a buddy reviewing every PR; Month 2-3 -- take a feature solo with async check-ins only.

Buddy: Not yet assigned. Do not default to the tech lead -- they already own 3 of the last 4 incident resolutions and are the bottleneck /team flagged last quarter. Recommend @engineer-b, who has the most recent onboarding experience (joined 6 months ago) and lighter current load.

Tooling & access: Repo access, cloud sandbox credentials, and local-env docs should all be requested the week before start date -- last hire's first commit was delayed 4 days waiting on access requests filed on day one.

Early signal (n/a -- pre-start): Once ramping, watch for whether questions route only to the assigned buddy or get pulled back to the tech lead; that pattern is the earliest sign the buddy assignment isn't sticking.

Recommended next step: Assign @engineer-b as buddy and file access requests today, one week before start date.

Reference

See ../../docs/FIVE_PILLARS.md and ../team/SKILL.md for the full team-health assessment this feeds into.