We keep hearing about the Brandon Hall Group study: strong onboarding improves productivity by 70%+ and retention by 82%.
But what does “strong” actually mean? What separates the 12% from the 88%?
I’ve been through enough onboarding experiences - good and bad - to have some opinions.
What Strong Onboarding Includes
1. Pre-boarding That Actually Works
Before day 1:
- Laptop arrives configured
- All accounts created and tested
- Buddy assigned and introduced
- Welcome email with reading materials
- First week calendar pre-populated
The test: Can the new hire clone the repo and run the dev environment on day 1?
2. Structured First Week
Not: “Shadow someone and figure it out.”
But: A written schedule covering:
- Day 1: Orientation + manager welcome + team intros
- Day 2: Architecture overview + environment setup
- Day 3: First task assigned + pair programming
- Day 4-5: Work on starter project + daily check-ins
The test: Does the new hire know exactly what they should be doing every day?
3. Clear 30/60/90 Day Goals
Day 30:
- Has shipped code to production
- Understands team processes
- Has 1:1 relationships with all teammates
Day 60:
- Owns a feature independently
- Participates meaningfully in design discussions
- Can explain system architecture
Day 90:
- Operates with minimal supervision
- Contributes to code review quality
- Identifies improvement opportunities
The test: Does the new hire know what “success” looks like at each milestone?
4. Dedicated Support Structure
Buddy: Someone (not the manager) who answers daily questions, provides social connection, gives cultural context.
Mentor: Someone senior who helps with technical ramp, career discussions, longer-term guidance.
Manager: Sets expectations, provides feedback, removes blockers, builds relationship.
The test: Does the new hire have three distinct people supporting different aspects of their ramp?
5. Regular Feedback Loops
Not: Waiting until performance review to learn they’re off track.
But:
- Daily informal feedback in week 1
- Weekly structured feedback in month 1
- Formal 30/60/90 day reviews
- Permission to give feedback to the company about onboarding
The test: Does the new hire know how they’re doing at all times?
The Common Failure Modes
| Component |
Weak Version |
Strong Version |
| Pre-boarding |
“We’ll get you set up on day 1” |
“Everything is ready before day 1” |
| First week |
“Shadow Sarah” |
“Here’s your written schedule” |
| Goals |
“Just get up to speed” |
“Here are your 30/60/90 milestones” |
| Support |
“Ask anyone if you have questions” |
“Here are your buddy, mentor, and manager” |
| Feedback |
“You’re doing fine” |
“Here’s specific feedback on your code/communication/process” |
Strong onboarding isn’t complicated. It’s just… deliberate.
The 30/60/90 day framework that works - with actual examples:
Day 30 Milestones
Technical:
- Dev environment runs without help
- Has submitted at least 5 PRs (any size)
- Has merged at least 2 PRs
- Can navigate codebase to find where features live
- Understands deployment process (even if not deploying alone)
Process:
- Knows sprint/kanban workflow
- Attends all required meetings, knows what they’re for
- Uses correct tools for communication (what goes to Slack vs email vs Jira)
Relationships:
- Has had 1:1 with every team member
- Knows who to ask about different domains
- Has social connection beyond just work
Checkpoint: Manager assesses: “On track” / “Needs support” / “Concern”
Day 60 Milestones
Technical:
- Has owned a feature from ticket to production
- Provides useful feedback in code reviews
- Can explain core system architecture to someone else
- Has fixed a bug independently
Process:
- Participates actively in planning/estimation
- Manages own work queue with minimal oversight
- Knows how to escalate blockers
Relationships:
- Collaborates with engineers outside immediate team
- Has working relationship with relevant PM/designer
Checkpoint: Manager + skip-level review trajectory.
Day 90 Milestones
Technical:
- Operates at expected level for role
- Identifies technical improvements independently
- Can onboard others in area of expertise
- Trusted with production access and on-call (with support)
Process:
- Contributes to team processes and standards
- Helps estimate work accurately
Relationships:
- Is a positive team culture contributor
- Has begun mentor/buddy role for others (if appropriate)
Checkpoint: Full performance review. Is onboarding complete?
The Key: Make It Checkable
Every milestone is a checkbox. Either it’s done or it’s not.
“Getting up to speed” is vague. “Has submitted 5 PRs” is measurable. “Understands the codebase” is subjective. “Can explain architecture to someone else” is demonstrable.
Buddy programs and why 87% of organizations report they’re effective:
The HCI research:
87% of organizations that assign a buddy or mentor during onboarding say it’s an effective way to speed up new-hire proficiency.
But there’s a catch: effective buddy programs are not the same as existing buddy programs.
What makes buddy programs fail:
- Random assignment: Picking whoever is available, not who’s a good match
- No guidance: “Be their buddy” without explaining what that means
- No time allocation: Buddy is expected to do this on top of regular work
- No accountability: Nobody checks if buddy is actually meeting with new hire
- Wrong seniority: Assigning another new-ish person as buddy
What makes buddy programs work:
1. Selection criteria
- Has been at company 1+ year
- Strong performer (they model good behavior)
- Good communicator
- Volunteered for the role
2. Clear responsibilities
| Week |
Buddy Responsibility |
| Pre-start |
Welcome email, personal introduction |
| Week 1 |
4+ hours together, lunch, Slack availability |
| Weeks 2-4 |
2+ hours together, answer questions |
| Months 2-3 |
Weekly check-in, ongoing relationship |
3. Protected time
Buddy’s regular workload is reduced by 10-15% during active onboarding. This is visible to their manager and accounted for in capacity planning.
4. Training
30-minute “how to be a buddy” session covering:
- What new hires typically struggle with
- What questions to ask
- How to escalate concerns
- What NOT to do (gossip, dump information, etc.)
5. Feedback loop
New hire rates their buddy at day 30. Buddy ratings affect whether they’re invited to be a buddy again.
The impact:
Google found new hires with buddies reached full efficiency 25% faster than those without. Our data is similar - about 3 weeks difference in time-to-productivity.
The technical vs cultural onboarding balance is something engineering teams often get wrong.
The typical mistake:
Engineering focuses entirely on technical ramp:
- Here’s the codebase
- Here’s the tech stack
- Here are the tools
- Ship this feature
Meanwhile, HR handles “culture”:
- Company values video
- Harassment training
- Benefits overview
- Office tour
Neither covers the team culture that actually affects daily work.
What’s missing:
1. How decisions get made
- Who has authority over what?
- How do we handle disagreements?
- What’s the escalation path?
- How much autonomy do ICs have?
2. Communication norms
- When do we use Slack vs email vs meeting?
- What does “urgent” mean here?
- How do we give feedback?
- What’s the meeting culture?
3. Quality expectations
- What does “good enough” look like?
- How much testing is expected?
- What’s the code review depth?
- How do we handle tech debt?
4. Work-life norms
- What are actual working hours?
- What’s the on-call expectation?
- Is weekend work normal or emergency-only?
- How do people take PTO here?
Our approach:
Week 1: 50% technical, 50% cultural
- Day 1: Company culture + team culture
- Day 2: Architecture + how we collaborate
- Day 3-5: Technical setup + process training
Ongoing: Continuous cultural context
- Buddy provides “how we really do things” perspective
- Manager explains reasoning behind decisions
- Team rituals include new hire explicitly
The ratio matters
A technically skilled engineer who doesn’t understand the culture will struggle. A culturally integrated engineer who needs more technical ramp will still succeed.
We’ve learned to front-load culture and let technical skills develop over months.