When I joined as VP Engineering 18 months ago, new engineers were taking 12 weeks to ship their first meaningful commit. Not a bug fix. Not a docs update. Their first actual feature contribution.
That’s three months of salary for near-zero output. Unacceptable.
I diagnosed the problem: Our onboarding was a synchronous bottleneck.
New engineers would:
- Wait for their mentor to be available (mentor was a senior engineer with actual work to do)
- Sit through scheduled intro meetings (coordinating calendars across timezones)
- Get live walkthroughs of systems (had to happen during overlap hours)
- Ask questions via Slack, wait for responses (async delays killed momentum)
Every step required waiting for someone else. In a distributed team across 6 timezones, that waiting compounded.
The Hypothesis
If our regular work is async-first, why isn’t onboarding?
We expect engineers to learn our systems independently, navigate our docs, make decisions without constant hand-holding. Yet onboarding treated new hires like they needed 24/7 supervision.
I built an async-first onboarding system. We cut ramp time to 6 weeks with higher satisfaction scores.
Here’s how.
The 6-Week Async Onboarding System
Week 1: Self-Guided Environment Setup
Goal: Local dev environment running, first deploy to staging
How:
- Loom video library (10-15 min videos for every setup step)
- Choose-your-own-adventure docs (macOS vs Linux, Docker vs local, etc.)
- Automated setup scripts with error handling
- Async help channel (#onboarding-help with 4-hour response SLA)
Why it works: Engineers learn at their own pace. Night owl? Set up at 11pm. Early bird? Start at 6am. No waiting for mentor availability.
Critical component: The Loom videos show real engineers (not perfect tutorials) doing the setup, hitting errors, and fixing them. New hires see the actual debugging process.
Week 2: Guided Code Exploration
Goal: Understand system architecture, navigate codebase confidently
How:
- “Treasure hunt” through codebase (10 questions that force you to read code)
- “Where is user authentication handled?”
- “How does our caching layer work?”
- “Find three examples of API error handling - which pattern is best?”
- Annotated PR library (senior engineers’ PRs with detailed comments explaining decisions)
- Architecture decision records (ADRs) for every major system
Why it works: Active exploration beats passive reading. Asking engineers to find answers (with guidance) builds mental models better than lectures.
Week 3: “First Fix” - Pre-Scoped Starter Issues
Goal: Ship actual code to production
How:
- Curated “good first issues” that are genuinely useful (not just busywork)
- Full context provided: why it matters, customer impact, suggested approach
- Pair with async buddy (not assigned mentor - anyone can help)
- PR review treated as learning moment (reviewers asked to explain not just what but why)
Why it works: Shipping to production Week 3 builds confidence. The issues are scoped small enough to complete but meaningful enough to matter.
Example issue: “Add validation to email field in signup form (currently accepts invalid formats, causing 200+ support tickets/month)”
Small scope, real impact, clear value.
Week 4: Pairing Rotation
Goal: Learn team practices, build relationships
How:
- Rotate through 4-5 different engineers (each pairs for half a day on their current work)
- Mostly async handoff (“here’s what I’m working on, here’s where I’m stuck, wanna pair?”)
- Sync pairing sessions scheduled at new hire’s convenience
- Written reflections after each pairing (what did you learn, what surprised you)
Why it works: Exposure to different work styles and problem-solving approaches. Builds relationships across team, not just with assigned mentor.
Week 5: Feature Ownership (With Mentor Shadowing)
Goal: Own a small feature end-to-end
How:
- Real feature from roadmap (not synthetic training exercise)
- New hire is DRI (Directly Responsible Individual)
- Mentor shadows async (reviews docs, available for questions, doesn’t drive)
- Weekly async check-in doc (progress, blockers, learnings)
Why it works: Accountability builds competence. When you’re the DRI, you figure things out. Mentor support prevents flailing.
Week 6: First Solo Feature
Goal: Ship independently with minimal support
How:
- Feature scoped appropriately for skill level
- Async check-ins with manager (not daily standups)
- Mentor available but not actively involved
- Retrospective at end of week (what worked, what was hard, what support do you need)
Why it works: Proof of independence. By week 6, engineer is contributing at 70-80% velocity of team average.
Critical Components That Make This Work
1. Pre-Recorded Loom Library
We maintain 50+ Loom videos covering common questions:
- How to run tests locally
- How to debug production issues
- How our deployment pipeline works
- How to write good commit messages (with examples)
Updated quarterly. Treated like production code (stale videos get flagged and re-recorded).
2. “Choose Your Own Adventure” Documentation
Not linear docs everyone must read. Branching paths based on role, experience, learning style.
Example: “Setting Up Local Environment”
- Path A: Experienced with Docker → 5-step quick start
- Path B: New to Docker → 15-step detailed guide with explanations
- Path C: Prefer video → Loom walkthrough
New hires choose what fits their background.
3. Async Buddy System
Not assigned mentor. Any engineer can be a buddy. Response within 4 hours expected, not same-time.
New hire posts in #onboarding: “Stuck on authentication error, here’s what I tried…”
Whoever’s available responds. Distributed load across team, no single bottleneck.
4. Weekly Async Reflection Prompts
Manager sends reflection questions each Friday:
- What did you ship this week?
- What was harder than expected?
- What surprised you about how we work?
- What support do you need next week?
New hire writes responses async. Manager reviews and responds. Builds relationship without requiring scheduled 1-on-1s (though those happen too, just less frequently).
5. Cohort Slack Channel
New hires who join in the same month get a cohort channel (#onboarding-cohort-march-2026).
Peer support. They ask each other “stupid questions” without fear. They share resources. They commiserate about confusing parts.
Creates camaraderie without forcing virtual social time.
The Results
Quantitative:
- Average time to first meaningful commit: 12 weeks → 6 weeks
- Onboarding satisfaction score: 6.2/10 → 8.7/10
- Mentor burden: 20+ hours/onboarding → 5 hours/onboarding
- First-year retention: 78% → 91%
Qualitative:
- Junior engineers reported preferring async (less pressure, learn at own pace)
- Senior engineers relieved to not be full-time mentors
- New hires felt empowered, not hand-held
The Trade-Offs
This isn’t free. It requires:
Upfront work: Building the Loom library, writing choose-your-own-adventure docs, curating good first issues - this took 3 months of dedicated effort.
Ongoing maintenance: Loom videos go stale. Docs get outdated. Starter issues need refreshing. We dedicate 5 hours/month to onboarding maintenance.
Cultural discipline: Async onboarding only works if your team actually responds in the #onboarding-help channel within 4 hours. That requires discipline and culture.
Not for all companies: If you’re 10 people and everyone sits in an office, this is overkill. Just have new hires shadow someone. Async onboarding is for distributed teams at scale.
The Key Insight
Junior engineers actually prefer async onboarding.
We assumed they needed synchronous hand-holding. Turns out, they prefer:
- Learning without the pressure of someone watching
- Trying things, failing privately, figuring it out
- Asking questions in writing (less intimidating than interrupting someone)
- Working at their own pace (not constrained by mentor’s calendar)
The myth is that async is hard for junior people. The reality: async is empowering.
The Question
How do you onboard in distributed teams?
Specifically curious about:
- What’s your time-to-first-meaningful-contribution?
- Async vs sync onboarding approaches?
- How do you balance structure (clear path) with flexibility (learn at your own pace)?
- What surprised you about what works vs what doesn’t?
Onboarding is the first impression of your engineering culture. Get it right and people stay. Get it wrong and they leave (or never ramp).