leadershipbusiness
Onboarding Plan
Design structured onboarding plans — for new hires, new customers, or new users — with milestone-based progression, success criteria, and feedback loops.
onboardingnew-hireramp-uptrainingcustomer-onboarding
Works well with agents
Works well with skills
onboarding-plan/
SKILL.md
Markdown| 1 | |
| 2 | # Onboarding Plan |
| 3 | |
| 4 | ## Before you start |
| 5 | |
| 6 | Gather the following from the user: |
| 7 | |
| 8 | 1. **Who is being onboarded?** (New hire, new customer, or new user — and their role/persona) |
| 9 | 2. **What does "fully ramped" look like?** (3-5 concrete outcomes that indicate onboarding is complete) |
| 10 | 3. **What is the expected ramp timeline?** (30 days, 60 days, 90 days) |
| 11 | 4. **Who is responsible for the onboarding?** (Manager, buddy, CSM, or self-guided) |
| 12 | 5. **What existing resources are available?** (Documentation, training videos, sandbox environments, mentors) |
| 13 | |
| 14 | If the user says "we just need a checklist," push back: "A checklist gets tasks done but doesn't ensure understanding. What should this person be able to do independently by the end of onboarding?" |
| 15 | |
| 16 | ## Onboarding plan template |
| 17 | |
| 18 | ### 1. Onboarding Overview |
| 19 | |
| 20 | Define the onboarding scope in a brief summary. |
| 21 | |
| 22 | ``` |
| 23 | Onboardee type: New hire — Senior Frontend Engineer |
| 24 | Team: Consumer Products |
| 25 | Timeline: 90 days (30-60-90 structure) |
| 26 | Onboarding owner: Engineering Manager + assigned buddy |
| 27 | Success measure: Ships first production feature independently by Day 75 |
| 28 | ``` |
| 29 | |
| 30 | ### 2. Pre-Start Preparation |
| 31 | |
| 32 | Complete before the onboardee's first day: |
| 33 | |
| 34 | - **Access provisioning**: List every system, tool, and repo they need access to. Include account names and who provisions each one. |
| 35 | - **Equipment setup**: Laptop, monitors, peripherals — ordered and configured. |
| 36 | - **Welcome packet**: Team org chart, key contacts, calendar invites for recurring meetings, links to onboarding docs. |
| 37 | - **Buddy assignment**: Assign a peer (not the manager) who is available for daily questions during the first two weeks. |
| 38 | - **First-week calendar**: Pre-schedule all Day 1-5 meetings and activities. An empty calendar on Day 1 signals disorganization. |
| 39 | |
| 40 | ### 3. Milestone-Based Progression |
| 41 | |
| 42 | Structure the plan into milestones, not a flat task list. Each milestone has a clear success criterion. |
| 43 | |
| 44 | **Milestone 1: Orientation (Days 1-7)** |
| 45 | |
| 46 | | Day | Activity | Owner | Success Criterion | |
| 47 | |-----|----------|-------|--------------------| |
| 48 | | 1 | Welcome meeting with manager — role expectations, 90-day goals | Manager | Goals documented and shared | |
| 49 | | 1 | Dev environment setup with buddy | Buddy | Can build and run the app locally | |
| 50 | | 2 | Architecture walkthrough — system overview, key services | Tech lead | Can draw the high-level architecture from memory | |
| 51 | | 3 | Codebase tour — repo structure, CI/CD pipeline, deployment process | Buddy | Successfully deploys a test change to staging | |
| 52 | | 4-5 | Read team docs — ADRs, runbooks, on-call playbook | Self | Completes reading, notes questions for buddy | |
| 53 | |
| 54 | **Milestone 2: Guided Contribution (Days 8-30)** |
| 55 | |
| 56 | | Week | Activity | Owner | Success Criterion | |
| 57 | |------|----------|-------|--------------------| |
| 58 | | 2 | Pick up first "good first issue" ticket | Manager | PR submitted with tests | |
| 59 | | 2-3 | Pair programming sessions (2-3 per week) | Buddy | Onboardee drives, buddy observes | |
| 60 | | 3 | Attend sprint planning and retro — observe, don't commit yet | Self | Understands team process | |
| 61 | | 4 | Ship first bug fix or small feature to production | Self | Code reviewed and merged | |
| 62 | | 4 | **30-day check-in with manager** | Manager | Written feedback exchanged both ways | |
| 63 | |
| 64 | **Milestone 3: Independent Contribution (Days 31-60)** |
| 65 | |
| 66 | | Week | Activity | Owner | Success Criterion | |
| 67 | |------|----------|-------|--------------------| |
| 68 | | 5-6 | Own a medium-sized feature end-to-end | Manager | Writes own technical approach, gets feedback | |
| 69 | | 6-7 | Participate in code review for others | Self | Provides substantive review comments | |
| 70 | | 7-8 | Shadow on-call rotation (if applicable) | On-call lead | Can handle a low-severity alert independently | |
| 71 | | 8 | **60-day check-in with manager** | Manager | Aligned on remaining ramp goals | |
| 72 | |
| 73 | **Milestone 4: Full Ramp (Days 61-90)** |
| 74 | |
| 75 | | Week | Activity | Owner | Success Criterion | |
| 76 | |------|----------|-------|--------------------| |
| 77 | | 9-10 | Ship a production feature independently | Self | Scoped, built, tested, deployed without hand-holding | |
| 78 | | 10-11 | Present a technical topic to the team | Self | Demonstrates domain understanding | |
| 79 | | 12 | Join on-call rotation (if applicable) | Manager | Added to rotation schedule | |
| 80 | | 12 | **90-day review** | Manager | Formal assessment against 90-day goals | |
| 81 | |
| 82 | ### 4. Feedback Loops |
| 83 | |
| 84 | Build feedback into the plan — don't wait for the end. |
| 85 | |
| 86 | - **Daily (Week 1)**: 15-minute buddy check-in. One question: "What's blocking you?" |
| 87 | - **Weekly (Weeks 2-4)**: 30-minute 1:1 with manager. Review progress against milestones. |
| 88 | - **Biweekly (Weeks 5-12)**: Standard 1:1 cadence. Shift from onboarding topics to regular work. |
| 89 | - **Formal checkpoints**: Written feedback at 30, 60, and 90 days. Both sides share what's working and what isn't. |
| 90 | |
| 91 | At each checkpoint, ask the onboardee: "What's one thing about the onboarding that should change for the next person?" |
| 92 | |
| 93 | ## Quality checklist |
| 94 | |
| 95 | Before delivering the plan, verify: |
| 96 | |
| 97 | - [ ] Every milestone has measurable success criteria, not just activities |
| 98 | - [ ] Pre-start preparation is complete — no "figure it out on Day 1" gaps |
| 99 | - [ ] A buddy is assigned and their responsibilities are documented |
| 100 | - [ ] Feedback checkpoints are scheduled at 30, 60, and 90 days |
| 101 | - [ ] The plan distinguishes between "do this task" and "be able to do this independently" |
| 102 | - [ ] Access provisioning lists specific systems, not "request access as needed" |
| 103 | - [ ] The 90-day completion criteria define what "fully ramped" means concretely |
| 104 | |
| 105 | ## Common mistakes to avoid |
| 106 | |
| 107 | - **Task lists without success criteria.** "Read the architecture docs" is a task. "Can draw the system architecture from memory and explain data flow" is a success criterion. Every activity needs a way to verify understanding. |
| 108 | - **No buddy assignment.** Managers are too busy for daily questions. A buddy at the same level provides low-friction support. Assign one explicitly and protect their time. |
| 109 | - **Information firehose on Day 1.** Spreading 8 hours of presentations across the first day guarantees nothing is retained. Limit Day 1 to setup, one key meeting, and one hands-on activity. |
| 110 | - **No feedback until 90 days.** If something is off at Week 2, waiting until Day 90 wastes everyone's time. Build in explicit checkpoints at 30 and 60 days with written feedback. |
| 111 | - **Treating onboarding as one-size-fits-all.** A senior hire needs less hand-holding on tools but more context on team dynamics and decision history. Adjust the plan to the person's level and background. |
| 112 |