| name | onboarding-program |
| description | Design structured onboarding that accelerates new hire productivity and reduces time-to-contribution. Use when bringing on engineers at any level or scaling the team. |
Onboarding Program
Build systematic onboarding that gets new engineers productive, confident, and integrated in weeks not months.
Context
You are a senior tech lead designing an onboarding program for $ARGUMENTS. Poor onboarding wastes 2-3 weeks of productivity per hire, creates cultural friction, and increases churn. Structured programs reduce ramp time by 40%.
Domain Context
- Onboarding ROI — every week saved in ramp-up is 2-5K per engineer. Investing in structure pays back in <1 month.
- First 90 days matter most — new hire impressions of culture, competence, belonging form in week 1. Early momentum predicts retention.
- Multimodal learning — docs, pair programming, live demos, self-study, projects. Different people learn differently. Offer variety.
- Belonging over knowledge — making someone feel part of the team matters more than technical knowledge. Isolation kills engagement.
Instructions
-
Design phase 1 (Days 1-5): Integration and context: Assign a buddy. Walk through culture, repo structure, deploy process. New hire should have working dev environment by day 2. Schedule team intro, first PR template review, read 3-5 key docs.
-
Design phase 2 (Week 2-3): Shallow contributions: Assign small, scoped tickets (fix typos, update docs, add tests). New hire should merge 2-3 PRs. Pair with different team members daily. Build familiarity with codebase without high stakes.
-
Design phase 3 (Week 4-6): Guided projects: Assign feature or bug with clear acceptance criteria and assigned mentor. Hands-on work with senior engineer pairing 50% of time. New hire drives implementation.
-
Design phase 4 (Week 7-12): Independent work and integration: New hire leads a small project solo with async check-ins. Participate in on-call shadows, code reviews, design discussions. Build relationships across team.
-
Measure and iterate: 30-60-90 day check-ins. Ask: "Are you productive? Do you understand our code? Do you feel part of the team?" Adjust based on feedback. Track time-to-first-PR, time-to-first-major-feature for improvement.
Anti-Patterns
- No structured plan: "Just throw them at the codebase" leads to 3+ weeks of confusion. Without scaffolding, new hires get stuck repeatedly, lose confidence.
- All lectures, no hands-on work: Recording tons of talks nobody watches. Early onboarding should be interactive and action-based. Docs are reference, not primary learning.
- Isolating new hires: Leaving them alone to figure things out. They get stuck, don't know who to ask, feel abandoned. Assign a buddy and schedule daily pair time for first 2 weeks minimum.
- Too many docs, no prioritization: Dumping 20 wikis pages on new hire. They don't know what matters. Curate 5-7 essential docs per role. Everything else is optional reference.
- No follow-up after week 4: Assuming onboarding is done once someone merged PRs. Check in regularly. Some onboarding gaps surface weeks later.
Further Reading
- Designing Your Life (Burnett & Evans) — integration and belonging
- "First 90 Days" (Michael Watkins) — leadership onboarding framework (applies to individual contributors)
- Gitlab's handbook onboarding checklist (public reference)
- The Culture Code (Daniel Coyle) — belonging as team accelerator
