90-Day Onboarding Plan with AI: Week-by-Week Breakdown and Prompts
What is AI-generated 90-day onboarding?
AI-generated 90-day onboarding is the practice of using large language models to produce structured week-by-week employee onboarding plans — including tasks, outcomes, success metrics, and 1:1 meeting agendas — tailored to a specific role, tech stack, and team context. It matters because structured onboarding significantly improves three-year retention (Brandon Hall Group), yet building a complete plan manually takes 15–20 hours of manager time. With LLMs, the same plan takes 2–3 hours, and adapting it for a different role takes 30–40 minutes.
TL;DR
- -Structured onboarding significantly improves three-year retention (Brandon Hall Group), but building a full 90-day week-by-week plan takes 15–20 hours manually — LLMs compress this to 2–3 hours.
- -The three-phase structure (Immersion days 1–30, Contribution days 31–60, Autonomy days 61–90) maps to measurable phase completion criteria, preventing ambiguous "probation passed" decisions.
- -Pre-start Week 0 preparation is the highest-leverage step: accounts, access, documentation links, and the first onboarding task in the tracker must exist before day one, not during it.
- -Red flags requiring immediate intervention: zero PRs in a week, no questions to the mentor (withdrawal, not confidence), the same code review comment appearing twice, negative feedback from 2+ colleagues.
- -Adapting a backend engineer plan to a different role (PM, QA, DevOps) via the role-adaptation prompt takes 30–40 minutes — 5 roles per quarter means 3 hours instead of 80.
Building a week-by-week onboarding plan for 90 days — one that accounts for the role, tech stack, company processes, and success metrics — takes 15–20 hours. That’s manager time nobody has, especially in teams under 50. The gap between “we know onboarding matters” and “we actually do it” is chronic.
LLMs cut this to 2–3 hours: generate the structure, fill in the weeks, define evaluation criteria, adapt for the specific position.
This article has a complete 90-day onboarding plan template, prompts for generating each block, and week-by-week checklists. It’s the same documentation automation approach covered in the AI SOP generation guide.
The Structure of a 90-Day Plan: Three Phases
90 days split into three phases. Each has a distinct goal, a set of tasks, and completion criteria.
Phase 1 (Days 1–30): Immersion. The new hire learns the context — product, tech stack, processes, team. The outcome: they can handle routine tasks without someone watching over their shoulder.
Phase 2 (Days 31–60): Contribution. Independent work on mid-complexity tasks. Participation in code reviews, sprint planning, on-call rotations. Outcome — stable performance at 60–70% of the team average.
Phase 3 (Days 61–90): Autonomy. Full-cycle ownership. Taking initiative on process improvements. Outcome — a full team member who makes decisions in their own area without needing a second opinion.
Phase 1: Immersion Phase 2: Contribution Phase 3: Autonomy
Days 1–30 Days 31–60 Days 61–90
──────────────────── ──────────────────── ────────────────────
Goal: understand Goal: stable Goal: full
context and complete contribution independence
routine tasks to the team
Mentor: daily Mentor: 2–3x Mentor: weekly
per week
Prompt for Generating the Base Onboarding Plan
Start with one detailed prompt. It generates the skeleton of the full plan, which you then refine phase by phase.
Generate a 90-day onboarding plan for the following position.
## Context
- Position: [Senior Backend Engineer]
- Stack: [Python, FastAPI, PostgreSQL, Redis, Docker, Kubernetes]
- Team size: [8 people]
- Methodology: [Scrum, 2-week sprints]
- Primary product: [B2B SaaS logistics platform]
- Key systems: [API Gateway, Order Service, Billing Service]
## Plan requirements
1. Break into 3 phases: Immersion (days 1–30), Contribution (days 31–60), Autonomy (days 61–90)
2. Break each phase down by week
3. For each week, specify:
- Concrete tasks (not abstract "read the documentation")
- Expected outcome
- Who is responsible for support (mentor, team lead, specific role)
4. For each phase, specify measurable completion criteria
5. Include both technical and organizational onboarding
6. Treat the first week as "week zero" — environment setup, access provisioning, introductions
## Format
Markdown table for each week. Columns: Day/Period | Task | Outcome | Owner
This prompt generates a 3–5 page plan. Quality scales directly with context detail: the more precisely you describe the stack, processes, and product specifics, the less manual editing you’ll need afterward.
Phase 1: Week-by-Week Immersion Plan (Days 1–30)
Week 0 (Before Day One)
Preparation starts before the person walks in. Prompt for generating a pre-start checklist:
Generate a checklist for preparing before a new employee starts as a
[Senior Backend Engineer].
Include categories:
- Access (Git, CI/CD, cloud, monitoring, chats)
- Hardware and software
- Documentation to review on day one
- Mentor assignment and first-week meeting schedule
- Onboarding task in the tracker (first PR)
Format: checklist with the person responsible for each item.
Pre-start checklist:
- Accounts: Git, Jira/Linear, Slack, company email
- Access: AWS/GCP console (read-only), CI/CD pipeline, staging environment
- Monitoring: Grafana, Sentry, logs (read-only)
- Documentation: links to architecture ADRs, API specs, runbooks
- Mentor assigned, first-week calendar filled
- Onboarding task created in tracker (description, acceptance criteria)
- Welcome message drafted for team channel (to be posted on day one)
Week 1: Orientation and First PR
| Day | Task | Outcome |
|---|---|---|
| 1 | Set up local development environment. Clone repositories, run the project locally | Project runs, tests pass |
| 1 | Team introductions: 15-minute 1:1 with each team member | Understanding of roles and responsibilities |
| 2–3 | Architecture overview: mentor walkthrough + independent reading of ADRs | Ability to draw a high-level system diagram |
| 3–4 | First task: fix a minor bug or add a test | First PR up for review |
| 5 | First-week retrospective with mentor | List of open questions and plan for week two |
Week 2: Processes and Codebase
| Day | Task | Outcome |
|---|---|---|
| 6–7 | Attend sprint planning (observer) | Understanding of prioritization process |
| 6–8 | Deep dive into one service (assigned by mentor) | Code walkthrough: key modules, data flow |
| 8–9 | Second task: feature or improvement in the studied service | PR with tests, passed code review |
| 10 | CI/CD pipeline review: how code gets deployed | Ability to independently deploy to staging |
Week 3: Expanding Context
| Day | Task | Outcome |
|---|---|---|
| 11–12 | Study a second service. Code reading + discussion with owner | Understanding of inter-service communication |
| 13–14 | Task spanning two services | PR with integration tests |
| 14–15 | Participate in reviewing others’ PRs (2–3 reviews) | Feedback from mentor on review quality |
Week 4: Consolidation and Assessment
| Day | Task | Outcome |
|---|---|---|
| 16–18 | Independent mid-complexity task | PR with no major review comments |
| 19 | Knowledge presentation: 15-minute architecture overview for mentor | Validation of system understanding |
| 20 | 1:1 with manager: Phase 1 assessment | Decision on moving to Phase 2 |
Phase 1 Completion Criteria:
- Local environment running stably
- 3+ PRs merged
- Ability to independently deploy to staging
- Familiar with the architecture of at least two key services
- Participated in one full sprint (planning → retrospective)
Phase 2: Week-by-Week Contribution Plan (Days 31–60)
Prompt for Phase 2 detail:
Detail Phase 2 (days 31–60) of the onboarding plan for [Senior Backend Engineer].
Context from Phase 1:
- Services studied: [Order Service, Billing Service]
- PRs merged: [5]
- Knows CI/CD, can deploy to staging
Phase 2 requirements:
1. Transition from observation to active participation in processes
2. Medium and complex-level tasks
3. Start participating in on-call (with backup)
4. First independent feature from design to deployment
5. Feedback from 3+ colleagues at the end of the phase
Format: week-by-week table with tasks and metrics.
Weeks 5–6: Independent Full-Cycle Tasks
| Period | Task | Outcome |
|---|---|---|
| Week 5 | Independent feature: from technical design to PR | Tech design approved by mentor, implementation started |
| Week 5 | First on-call (shadow): observe the on-call engineer | Understanding of incident handling process |
| Week 6 | Feature complete, deployed to staging, team demo | Feature running in staging, feedback received |
| Week 6 | Retrospective participation with a process improvement proposal | Active role in team processes |
Weeks 7–8: Expanding Influence
| Period | Task | Outcome |
|---|---|---|
| Week 7 | First independent on-call shift (with backup) | At least one ticket handled without escalation |
| Week 7 | Code reviews: 5+ reviews in the week | Constructive feedback, real issues found |
| Week 8 | Complex-level task (performance, refactoring, new integration) | PR with measurable improvement |
| Week 8 | 360-degree feedback from 3+ colleagues | Document with strengths and growth areas |
Phase 2 Completion Criteria:
- Independent feature shipped to production
- 10+ PRs merged (cumulative)
- Able to handle on-call without backup
- Code reviews rated as useful by colleagues
- 360-degree feedback with no critical issues
Phase 3: Week-by-Week Autonomy Plan (Days 61–90)
Prompt for Phase 3 detail:
Detail Phase 3 (days 61–90) of the onboarding plan for [Senior Backend Engineer].
Context:
- Phases 1 and 2 completed successfully
- Independently owns full-cycle tasks
- Participates in on-call rotations
- 360-degree feedback: [paste key points]
Phase 3 requirements:
1. Full autonomy within area of responsibility
2. Initiative: proposing process or code improvements
3. Mentorship: helping others (juniors, new hires)
4. Preparation for final probationary assessment
5. Defining ownership area
Format: week-by-week table + probationary period pass criteria.
Weeks 9–10: Ownership and Initiative
| Period | Task | Outcome |
|---|---|---|
| Week 9 | Define ownership area (service or domain) | Agreed with manager, documented |
| Week 9 | Initiative task: an improvement identified independently | Tech design and justification (ROI, impact) |
| Week 10 | Implement the initiative task | PR merged, impact measured |
| Week 10 | Help a colleague with a task outside own ownership area | Demonstration of cross-functional capability |
Weeks 11–12: Preparing for Assessment
| Period | Task | Outcome |
|---|---|---|
| Week 11 | Fully independent sprint: plan tasks, execute, demo | Sprint completed without escalations |
| Week 11 | Documentation: describe ownership area (architecture, runbook) | Documentation useful for future employees |
| Week 12 | Self-assessment: achievements, growth areas, development plan for next quarter | Document for final assessment |
| Week 12 | Final meeting with manager: probationary review | Pass/fail decision |
Probationary Period Pass Criteria:
- Performance at 80%+ of team average
- Ownership area defined and documented
- At least one initiative task shipped to production
- Able to independently handle on-call and incidents
- Positive feedback from 4+ team members
- No recurring critical comments in code reviews
Prompt for Adapting the Plan to a Specific Role
The base template is built around a backend engineer. To adapt it for other roles:
Adapt the 90-day onboarding plan for the role of [Product Manager / QA Engineer / DevOps / Designer].
Current plan (backend engineer):
[paste generated plan]
Changes for the new role:
1. Replace technical tasks with role-relevant ones
2. Keep the three-phase structure and weekly breakdown
3. Adapt phase completion criteria
4. Specify role-specific tools and processes
5. Retain organizational onboarding (introductions, processes, culture)
Example task adaptations:
- "First PR" → "First test plan" (QA) / "First PRD" (PM)
- "Code review" → "Test case review" (QA) / "Spec review" (PM)
- "On-call" → "Bug triage" (QA) / "Backlog prioritization" (PM)
Automating Checklists: Prompt for the Issue Tracker
A week-by-week plan only works when it lives inside a task tracker. In a Google Doc, it becomes a dead document nobody checks.
Prompt for generating tasks in tracker format:
Convert the week-by-week onboarding plan into a set of tasks for [Jira / Linear / Notion].
Requirements:
1. Each task is a separate ticket
2. Fields: title, description, assignee, due date (relative to start date),
labels (onboarding, phase-1/2/3), acceptance criteria
3. Milestone tasks for each phase (completion criteria)
4. Parent task for each week (epic or group)
5. Dependencies between tasks where applicable
Format: JSON array of objects, compatible with the [chosen tracker] API.
Example generated ticket:
{
"title": "Week 1: First PR",
"description": "Fix bug [link] or add a test for [module]. Goal — complete the full cycle: branch → code → tests → PR → review → merge.",
"labels": ["onboarding", "phase-1", "week-1"],
"due_date": "+5d",
"assignee": "new_hire",
"acceptance_criteria": [
"PR created and passed CI",
"At least one approving review",
"PR merged to main"
]
}
1:1 Meetings: Prompt for Agenda and Questions
Unstructured 1:1s between a manager and a new hire always drift toward “so, how are things going?” — which tells you nothing.
Generate an agenda for a 1:1 meeting on [week N] of onboarding.
Context:
- Phase: [1/2/3]
- Current week tasks: [list]
- Known challenges: [if any]
- Mentor feedback: [if any]
Agenda structure:
1. Check-in (5 min): general status, blockers
2. Progress (10 min): what's done, what didn't work, why
3. Feedback (5 min): what's going well, what to adjust
4. Planning (5 min): next week's tasks, expectations
5. Questions (5 min): open questions from both sides
For each item, suggest 2–3 specific questions tied to the current week.
The prompt spits out an agenda in 30 seconds. Without AI, prepping for a 1:1 takes 10–15 minutes — reviewing tasks, framing questions, figuring out what to actually say. Over 12 weeks of onboarding, that’s 2–3 hours spent purely on meeting prep.
Metrics: How to Measure Onboarding Quality
Onboarding without metrics is theater. You don’t know if it’s working until it’s already too late. Prompt for generating a metrics system:
Suggest metrics for evaluating 90-day onboarding quality.
Categories:
1. Speed to productivity (time-to-productivity)
2. Work quality (code, documentation, decisions)
3. Team integration (communication, processes)
4. Satisfaction (employee and team)
For each metric, specify:
- What we're measuring
- How we're measuring it (data source)
- Target value by phase
- Red flag (when intervention is needed)
Key Metrics by Phase:
| Metric | Phase 1 | Phase 2 | Phase 3 |
|---|---|---|---|
| PRs/week | 1–2 | 3–4 | 4–5 |
| Time to first review | < 3 days | < 1 day | < 4 hours |
| PR comments (average) | 5+ (normal) | 2–3 | 0–1 |
| Tasks without escalation | 50% | 80% | 95% |
| Mentor rating (1–5) | 3+ | 4+ | 4+ |
Red flags that need attention: zero PRs in a week, no questions for the mentor (that’s withdrawal, not confidence), the same code review comment appearing twice, negative feedback from 2+ colleagues.
Final Checklist: Implementing the 90-Day Plan
Generating the plan is 20% of the work. The other 80% is running it consistently and catching problems early.
Before launch:
- Generate the base plan (meta-prompt from the section above)
- Adapt for the specific role and level
- Load tasks into the tracker
- Assign mentor, align on their workload (5–8 hours/week in Phase 1)
- Prepare access and environment (Week 0 checklist)
During onboarding:
- Weekly 1:1s with AI-generated agendas
- Metrics assessment by phase
- Adjust the plan when deviations occur (generate alternative tasks via LLM)
- Collect mentor feedback after each phase
After completion:
- Final assessment against Phase 3 criteria
- Onboarding process retrospective: what worked, what to improve
- Update the plan template based on the retrospective
- Transfer results to the knowledge base for future hires
A plan generated once for a Senior Backend Engineer adapts to a mid-level position in 15 minutes — drop the ownership tasks, add more mentorship checkpoints. A different role via the meta-prompt takes 30–40 minutes including manual fine-tuning. Five positions per quarter: 3 hours instead of 80.
Need help with AI-powered onboarding systems? I help startups build AI products and automate processes — belov.works.
FAQ
How do you handle a new hire who completes Phase 1 tasks but clearly lacks the depth the role requires?
The phase completion criteria serve as the decision gate — not calendar time. If a hire hits the checkboxes (3+ PRs merged, can deploy to staging, passed the architecture walkthrough) but the mentor flags shallow understanding, schedule an explicit “extended Phase 1” for two more weeks with a targeted learning plan generated via the LLM. The key is making this a structured conversation with written criteria, not a vague “needs more time.” Both the manager and the hire should agree on exactly what “ready for Phase 2” looks like before extending.
Should the onboarding plan be different for remote versus in-office employees?
The structure stays the same, but the Week 1 tasks change. Remote onboarding needs explicit asynchronous communication norms in the plan (which channels for which questions, expected response times, video-on meeting culture) and more frequent 1:1 check-ins in Phase 1 — daily 15-minute calls instead of weekly. The “15-minute 1:1 with each team member” in Week 1 becomes a scheduled video call rather than a walk to someone’s desk. Add a “remote tooling” section to Week 0: ensure the hire has a working video setup, access to async collaboration tools, and clear documentation on how the team operates across time zones.
What is a realistic mentor time commitment, and how do you prevent it from cannibalizing the mentor’s own output?
Phase 1 requires 5–8 hours per week of mentor time — primarily pair programming, architecture walkthroughs, and PR reviews. This is a real cost, not an estimate. Protect the mentor’s productivity by limiting them to one onboardee at a time and explicitly reducing their sprint commitments by 20–30% during Phase 1. In Phase 2, the commitment drops to 2–4 hours/week, and by Phase 3 it’s under 2 hours. Budget this into sprint planning from week one rather than treating it as “extra” work that doesn’t count toward team velocity.