Generate 30-60-90 Onboarding Plans That Teach the AI Stack in Week One

Workflow area: Hiring & Performance · Tier: Foundation · Hands-on time: ~25 minutes

The first month sets an engineer's defaults for years, and there's now a new default to set: how they work with AI on your codebase, under your policy, with your review standards. Hires arrive with wildly different AI habits — some prompt fluently but never verify, some distrust the tools entirely, some used agents at their last job with more autonomy than you allow. Leaving AI onboarding to osmosis means each hire inherits the habits of whoever sits nearest. A generated, tailored plan costs twenty-five minutes and makes the ramp measurable; putting the AI stack in week one makes the habits deliberate.

When to use — and when not to

• Use it for every engineering hirejunior through staff; the plan's content shifts by level but the structure holds.
• Use it for internal transfersthey skip the HR layer but need the team's AI norms, codebase context, and review standards just as much; transfers are the hires most often left to osmosis.
• Use it to fix onboarding you already rana hire who ramped before your AI policy existed can run week one's AI-stack track retroactively in an afternoon.
• Skip the generic versiona plan that doesn't name your systems, your policy, and this hire's actual first project is a template, not a plan; if you can't fill the inputs, gather them first.
• Skip using the plan as surveillance30-60-90 checkpoints are for the hire and their onboarding buddy to steer by, not a probation tripwire; the moment it reads as a test, people hide confusion, which is the exact opposite of what onboarding is for.

The recipe

1. 1.

   Gather the inputs that make it this hire's plan. Five things: the role and level, the first real project they'll touch, your team's AI policy (pb-25) and review standards for AI-generated code (pb-27 in this track), the tool stack with account/access steps, and the name of their onboarding buddy. Thin inputs produce a generic plan; this step is most of the work.

2. 2.

   Generate the plan with the AI-stack track built into week one.

   Copy

   Create a 30-60-90 onboarding plan. Inputs:
   - Hire: [ROLE, LEVEL, START DATE, relevant background]
   - First project: [WHAT + the team context they'll need]
   - Team AI policy summary: [APPROVED TOOLS, data rules,
     review gates, disclosure norms]
   - Stack: [REPOS, CI, observability, docs system, internal
     RAG/docs assistant if any]
   - Buddy: [NAME]
   
   Requirements:
   1. WEEK ONE includes an explicit AI-stack track: accounts
      provisioned for [TOOLS]; read and acknowledge the AI
      policy; set up the repo's context files (CLAUDE.md /
      rules files); one supervised session using AI on a real
      but low-stakes task WITH the buddy reviewing both the
      prompts and the verification steps.
   2. Verification habits are a named skill with practice
      reps: every AI-assisted change in month one gets a
      written "how I verified this" note in the PR.
   3. Each phase (30/60/90) has 3-5 outcomes stated as
      observable deliverables, not activities. Include the
      social ramp: named people to meet and why.
   4. Include a buddy checklist and a manager checkpoint
      agenda at day 30, 60, 90.
   Format: one page per phase, skimmable.
   

3. 3.

   Check the plan's shape before it ships. Good week-one output looks like:

   Copy

   WEEK 1 — AI-STACK TRACK (alongside codebase setup)
   □ Accounts: Copilot seat, Claude workspace — day 1 (IT ticket
     pre-filed by buddy)
   □ Read AI policy; 30-min walkthrough with [BUDDY] — day 2
   □ Tour the repo's CLAUDE.md: what context we give the model
     and why; add one improvement you noticed — day 3
   □ Supervised session: fix a good-first-issue using AI; buddy
     reviews prompts, output, and your verification — day 4
   □ First PR includes "how I verified" note — day 5
   

   The tells of a good plan: dates, owners, artifacts ("add one improvement to CLAUDE.md" beats "learn our AI setup"), and verification practiced on real work, not a sandbox.

4. 4.

   Wire in the internal-docs assistant as the self-serve layer. If you run an internal RAG assistant over your docs, week one includes using it as the first stop for "how does X work here" questions — with the honest caveat the hire needs on day one: the assistant is a map, not the territory; stale answers get reported (a great first contribution), and anything load-bearing gets confirmed against the source doc or a human. Learning to calibrate trust in internal AI is itself a verification rep.

5. 5.

   Run the checkpoints and feed the plan back. At each 30/60/90 checkpoint, review outcomes against the plan — including the AI-habit outcomes: are their verification notes substantive? Are they using AI where it helps and skipping it where it doesn't? Then harvest the fresh-eyes value: every confusion the hire hit is an onboarding-plan bug; fold the fixes into the template so the next generation costs ten minutes, not twenty-five.

Make it yours

• Small team or startup: compress to 2-3 outcomes per phase and merge buddy and manager (it's probably both you) — but keep the supervised AI session and the verification notes; small teams have the least review redundancy to catch confidently-wrong AI output later.
• Large org or GCC: week one's account provisioning goes through IT lead-time, so file access requests at offer-accept, not day one — an AI-stack track that starts "wait four days for your seat" teaches that the policy is decorative. Align the plan with any site-wide onboarding curriculum, and localize: the India-site plan names India-site people and norms, not the parent org's.
• Senior and staff hires: shift the AI track from "learn the tools" to "learn our boundaries" — the autonomy ladder settings, the no-AI zones, review standards they'll be enforcing on others — and add a 60-day outcome: one improvement proposed to the team's AI practices from their outside experience.

Quality check

• The AI stack is in week one, with a supervised repa plan that defers AI tooling to "when they're settled" sets the osmosis default it exists to prevent.
• Every outcome is observable"understands the architecture" fails; "shipped a change to the billing service with a verified-AI note" passes.
• Accounts were live on day oneaudit the last hire's actual provisioning dates; the gap between plan and IT reality is the plan's real quality score.
• Verification notes exist and have contentread two from the hire's first month; "tests pass" is not verification, "reproduced the edge case the model missed" is.
• The template improved after each hireif three hires produced zero template edits, the checkpoints aren't harvesting fresh-eyes findings.