The engineer resigned after six weeks. When we did the exit interview, the reason was painfully clear: "I had no idea what I was supposed to be doing. My manager was always in meetings. The codebase made no sense. I spent three weeks just trying to get my dev environment working."
This wasn't a bad hire—it was bad onboarding. The company had spent $40,000 recruiting this engineer and lost them because they didn't have a plan for the first 90 days.
After studying onboarding programs at over 75 engineering teams at SmithSpektrum, the pattern is consistent: companies with structured onboarding reach full productivity 40% faster and have significantly lower early-stage attrition[^1].
Here's the complete framework.
Why Onboarding Fails
Most engineering onboarding fails for predictable reasons.
No one owns it. HR thinks engineering owns technical onboarding. Engineering thinks HR owns the process. The new hire falls through the gap.
It's improvised every time. Each manager creates their own approach, leading to inconsistent experiences and reinvented wheels.
It's too short. A one-day orientation isn't onboarding—it's paperwork. Real onboarding takes 90 days.
It focuses on information, not integration. New hires get documentation dumps but no relationships, context, or sense of belonging.
No one measures it. If you don't track ramp time, you can't improve it.
The 90-Day Framework
Effective onboarding happens in three phases, each with distinct goals.
| Phase | Timeframe | Primary Goal |
|---|---|---|
| Foundation | Days 1-30 | Setup, context, first contribution |
| Integration | Days 31-60 | Relationships, deeper understanding |
| Acceleration | Days 61-90 | Independence, ownership |
Pre-Day 1: Before They Start
Onboarding starts before the first day. Friction on day one creates bad impressions that persist.
One week before start:
- Laptop ordered, configured, and ready
- Accounts created (email, Slack, GitHub, all tools they'll need)
- Manager introduction email sent
- Onboarding buddy assigned and introduced
- First week calendar populated
- Welcome package shipped (if remote)
Day before start:
- Manager confirms start time and logistics
- Buddy confirms they're available
- All access confirmed working
- Team notified of new hire
The goal: zero technical friction on day one. Every hour spent fighting access issues is an hour not building context.
Days 1-7: The First Week
The first week sets the tone. New hires form lasting impressions about whether they made the right choice.
Day 1 Checklist:
| Time | Activity | Owner |
|---|---|---|
| First hour | Welcome, logistics, office tour (or remote setup) | Manager |
| Hour 2 | HR paperwork, benefits enrollment | HR |
| Hour 3 | 1:1 with manager: role expectations, 90-day goals | Manager |
| Hour 4 | Lunch with team | Team |
| Afternoon | Dev environment setup | Buddy |
| End of day | Check-in with buddy | Buddy |
Days 2-5 Checklist:
- Meet all immediate team members 1:1 (30 min each)
- Architecture overview session
- Product overview session
- Complete first "starter task" (something small but real)
- Daily check-in with buddy
- Read key documentation (identified in advance)
- Set up local development environment fully working
- Access all relevant dashboards and tools
- Join relevant Slack channels and meetings
- End-of-week 1:1 with manager
The starter task matters. It should be small enough to complete in 1-2 days, real enough to provide context, and visible enough to create a sense of contribution. Fix a small bug, update documentation, add a minor feature—something that ships.
Days 8-30: Building Foundation
With basics in place, focus shifts to understanding and first real contributions.
Week 2:
- Complete comprehensive codebase walkthrough
- Shadow a senior engineer for a day
- Attend sprint planning/standup (as observer initially)
- Complete first PR that touches core codebase
- Meet with key stakeholders (PM, designer, etc.)
- 1:1 with skip-level manager
Weeks 3-4:
- Take on first "real" project (small feature or bug fix)
- Participate actively in code reviews (both giving and receiving)
- Complete any required training (security, compliance)
- Write documentation for something you learned
- 30-day check-in with manager (formal)
- Feedback survey completed
30-Day Milestones:
| Milestone | Description |
|---|---|
| Environment | Can build, test, and deploy independently |
| Codebase | Understands major components and can navigate |
| Process | Knows how team works, can participate in ceremonies |
| Relationships | Has met all team members and key stakeholders |
| Contribution | Has shipped at least one meaningful change |
Days 31-60: Integration
The second month focuses on deepening understanding and building independence.
Integration Goals:
- Own a medium-sized project end-to-end
- Conduct code reviews independently (not just participating)
- Understand on-call responsibilities and shadow on-call rotation
- Present something to the team (tech talk, project update)
- Build relationships beyond immediate team
- Identify area for future specialization or ownership
- 60-day manager check-in
Key Activities:
| Activity | Purpose |
|---|---|
| Cross-functional meetings | Understand how engineering fits in company |
| Technical deep-dives | Build expertise in specific areas |
| Customer/user exposure | Understand who you're building for |
| Architecture decisions | See how the team makes technical choices |
| Incident response (shadow) | Learn how team handles production issues |
By day 60, the new hire should be operating at 60-70% of full productivity on familiar work and able to take on projects with moderate supervision.
Days 61-90: Acceleration
The third month transitions from "new hire" to "team member."
Acceleration Goals:
- Own significant feature or project
- Participate in on-call rotation
- Mentor or help onboard next new hire (if applicable)
- Contribute to technical decisions
- Identify growth goals for next quarter
- 90-day formal review
90-Day Milestones:
| Milestone | Description |
|---|---|
| Productivity | Operating at 80%+ of full capacity |
| Independence | Can take projects from requirements to deployment |
| Influence | Contributing to team decisions |
| Growth | Has clear development goals |
| Belonging | Feels part of the team |
The Onboarding Buddy Program
The most effective onboarding element is a dedicated buddy—someone other than the manager who's responsible for the new hire's day-to-day integration.
Buddy Responsibilities:
| Responsibility | Frequency |
|---|---|
| Daily check-ins (first two weeks) | Daily, 15 min |
| Weekly check-ins (weeks 3-8) | Weekly, 30 min |
| Answer questions | As needed |
| Introduce to team members | First two weeks |
| Explain unwritten rules | Ongoing |
| Provide safe feedback channel | Ongoing |
Good Buddy Characteristics:
- Strong performer (but not necessarily senior)
- Good communication skills
- Patient and approachable
- Understands team culture well
- Available (not overloaded with projects)
Don't assign buddies who are too senior—they're often too busy. Mid-level engineers with 1-2 years at the company often make the best buddies.
Documentation That Matters
New hires need documentation, but they need the right documentation in the right order.
Essential Documents (Day 1):
| Document | Purpose |
|---|---|
| Dev environment setup | Get them coding |
| Team/org chart | Understand who's who |
| Key tools and access | Know what to use |
| Emergency contacts | Know who to ask |
Important Documents (Week 1):
| Document | Purpose |
|---|---|
| Architecture overview | Understand the system |
| Coding standards | Know expectations |
| Sprint/process guide | Know how team works |
| On-call runbook | Understand operations |
Helpful Documents (Month 1):
| Document | Purpose |
|---|---|
| Technical decision records | Understand why things are built this way |
| Historical context | Avoid repeating past mistakes |
| Roadmap | Understand where we're going |
| Team norms | Understand culture |
The key: curate, don't dump. A 500-page wiki is useless. A prioritized reading list with the 10 most important documents is invaluable.
Remote Onboarding Adjustments
Remote onboarding requires extra intentionality around connection.
| Challenge | Solution |
|---|---|
| No casual office interactions | Scheduled virtual coffee chats |
| Hard to ask quick questions | Dedicated Slack channel with buddy |
| Feeling isolated | Daily video check-ins first two weeks |
| Missing context | Over-document decisions and discussions |
| Equipment issues | Ship equipment early, test before day 1 |
Remote-specific additions:
- Virtual office tour (recorded walkthrough of how team works)
- More frequent video calls (not just Slack)
- Intentional introduction to everyone (don't assume it happens)
- Explicit invitation to meetings (don't assume they know to join)
- Regular pulse checks on isolation/belonging
Measuring Onboarding Success
You can't improve what you don't measure.
Quantitative Metrics:
| Metric | How to Measure | Target |
|---|---|---|
| Time to first commit | Days from start to merged PR | < 5 days |
| Time to full productivity | Manager assessment | < 90 days |
| 90-day retention | Did they stay? | > 95% |
| New hire satisfaction | Survey at 30/60/90 days | > 4/5 |
Qualitative Signals:
| Signal | What to Look For |
|---|---|
| Confidence | Are they asking fewer basic questions? |
| Independence | Are they taking initiative? |
| Belonging | Do they participate in team discussions? |
| Quality | Is their code meeting standards? |
Run a 90-day retrospective with each new hire: "What worked? What didn't? What would have helped?" Feed this back into improving the program.
Common Mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Information overload day 1 | Overwhelm, nothing retained | Spread information over weeks |
| No clear first task | Confusion, imposter syndrome | Define starter task in advance |
| Manager too busy | New hire feels abandoned | Protected manager time or strong buddy |
| Sink or swim mentality | Extended ramp, early attrition | Structured support |
| One-size-fits-all | Doesn't account for experience level | Adapt based on seniority |
| Ends after week 1 | Premature independence | Full 90-day program |
The engineer who quit after six weeks? We rebuilt that company's onboarding from scratch. Clear buddy assignments, structured first-week schedule, starter tasks defined, 90-day milestones. Their next three hires all stayed past the one-year mark and ramped to productivity in under three months.
Onboarding isn't orientation. It's a 90-day investment in your new hire's success.
References
[^1]: SmithSpektrum onboarding program data, 75+ engineering teams, 2020-2026. [^2]: BambooHR, "The Definitive Guide to Onboarding," 2024. [^3]: Harvard Business Review, "Onboarding Isn't Enough," 2023. [^4]: Google re:Work, "Guide: Set up new team members for success," 2022.
Need help building an engineering onboarding program? Contact SmithSpektrum for templates and implementation support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum