Remote Onboarding in Async-First Culture: New Hires Ramp 40% Slower. What Are We Missing?

[cto_michelle]

Here’s the data that’s keeping me up at night.

The Ramp Time Problem

Comparing new engineer productivity across three eras:

Co-located (2019):
Engineers fully productive in 4-6 weeks

Remote, sync-heavy (2020-2021):
Engineers fully productive in 6-8 weeks

Remote, async-first (2024-2026):
Engineers fully productive in 8-10 weeks

We’re 40% slower than we used to be. And I don’t know how to fix it.

Why This Matters

• 40% slower ramp = 40% less value in first quarter
• New hire frustration = retention risk (two engineers left in first 90 days last year)
• Compounding problem as team grows

What We Have (Extensive Async Onboarding)

We’ve invested heavily in async infrastructure:

• 200+ page Notion wiki (comprehensive documentation)
• Loom video library (50+ hours of content)
• Shadowing program (read real project docs)
• Slack onboarding channel (dedicated support)
• Assigned buddy (experienced engineer paired with each new hire)

On paper, it looks great.

What New Hires Actually Say

From exit interviews and 90-day surveys:

“Too much documentation. I don’t know where to start.”

“Felt alone and confused for the first month.”

“I didn’t know what I didn’t know—couldn’t ask good questions async.”

“My buddy answered questions, but I felt like I was bothering them.”

“Hard to learn culture and norms through text.”

What I Think Is Happening

Async is great for explicit knowledge:

• How to deploy code
• Architecture decisions
• API documentation

Async fails at tacit knowledge:

• Cultural norms (“how we work here”)
• Unwritten patterns (“why we do it this way”)
• Knowing what questions to ask

New hires lack pattern recognition to navigate async effectively.

Experienced engineers know: “This is similar to that project from 2024.”
New hires don’t have that context.

Experiments We’ve Tried

More comprehensive docs:
Didn’t help. 200 pages → 300 pages = more overwhelming.

Required buddy check-ins:
Helped slightly, but felt forced. Buddies and new hires both said it was artificial.

Cohort-based onboarding:
Helped (peer support), but doesn’t scale. Hard to batch hires.

Sync “office hours”:
Helped (real-time questions), but timezone limited. Singapore new hires can’t join Austin office hours.

Current Hypothesis

Async-first culture requires sync-heavy onboarding ramp.

• First 2-4 weeks: Over-index on sync (daily check-ins, pairing sessions, meeting attendance)
• Gradual transition to async as new hire builds context and relationships

The Resistance I’m Facing

“But we’re async-first! This contradicts our culture!”

“Sync onboarding doesn’t scale across timezones!”

My Counterargument

Async is optimization for experienced team members who already have context.

New hires aren’t experienced yet. Different phase, different needs.

4-week sync investment pays off in faster long-term ramp.

Questions for the Community

1. How are you handling remote onboarding in async cultures?

2. Is 40% slower ramp just the cost of async-first? Or are we missing something?

3. What’s worked for teaching tacit knowledge remotely?

4. Are there tools/approaches that make async onboarding actually effective?

I refuse to believe we’re stuck with 10-week ramps. There has to be a better way.

[eng_director_luis]

Michelle, this resonates. We’re seeing the exact same 40% slower ramp. Here’s my theory on why.

The Onboarding Paradox

Async-first works because of shared context.

Experienced engineers have:

• Mental models of how systems work
• Codebase knowledge
• Relationship trust with teammates

New hires have none of that.

Async amplifies the context gap instead of closing it.

The Cultural Contradiction

Async-first culture = Minimal sync meetings, maximize flow time

New hires learn best through = Sync interaction, real-time feedback, observation

Result: Culture optimized for seniors accidentally excludes juniors.

What’s Working at Our Fintech Company

First 30 days: “Onboarding Exception” to async-first rule

New hire gets:

• Daily 1:1 with manager (15 min, non-negotiable)
• Weekly pairing sessions with 3-4 rotating team members
• Weekly “Ask Me Anything” with engineering leadership
• Join all team meetings (even if just observing)

After 30 days: Graduate to standard async-first mode.

Why This Works

1. Frontloads relationship building
Trust enables async later. Can’t build trust purely async.

2. Rapid feedback loops
Correct misunderstandings early, before they compound.

3. Observing meetings teaches culture
Faster than reading 200-page wiki. You see “how we disagree” and “what good looks like.”

4. Time-boxed
Not permanent sync overhead. 30 days, then transitions.

The Metrics We Track

• Time to first PR merged
• Time to first independent feature shipped
• 90-day retention rate
• Buddy/manager satisfaction with onboarding

Early Results (Small Sample, N=6)

Time to productivity:
Back to 6-week range (vs 10 weeks with pure async)

New hire satisfaction:
8.2/10 (vs 6.5/10 with pure async onboarding)

To Your “Doesn’t Scale Across Timezones” Concern

True, but:

• Hire in clusters (2-3 people in same timezone)
• Share onboarding buddy across timezone pairs
• Record key meetings for async consumption

Not perfect, but better than current state.

The Culture Framing That Helped

“Async-first for execution, sync for learning.”

Not abandoning async culture. Just recognizing that learning phase is different from execution phase.

Onboarding is learning. Production work is execution. Different modes.

[maya_builds]

The design industry solved this decades ago: apprenticeship model.

The Problem with Docs/Videos

Passive learning doesn’t build skills.

You can watch 50 hours of Loom videos and still not know how to do the work.

Our Apprenticeship Approach

New designer shadows experienced designer for first 2 weeks. Not just watching—active participation.

Week 1: Observe and Ask

• Daily pairing sessions (2 hours sync)
• Shadowing real work
• Real-time questions: “Why did you choose that component?”

Week 2: Pair on Real Work

• Shadowing flips: Senior watches junior
• Junior does the work, senior guides
• Immediate feedback

Week 3: Solo Work with Daily Review

• Junior takes solo tasks
• 30-minute daily review with mentor
• Still safety net

Week 4: Full Autonomy

• Weekly check-ins only
• Junior is ramped

Why This Works for Tacit Knowledge

See decisions in real-time:
“Why did you choose this pattern over that one?” (Can’t get this from docs)

Learn norms through modeling:
“How do we give feedback here?” (See it happen, not read about it)

Build deep relationship with one person:
Then expand network from there.

Practice in low-stakes environment:
Before solo performance matters.

How It Works Across Timezones

Pair new hire with mentor in same/similar timezone.

Mentor-mentee schedule daily sync (30 min). Rest of team stays async.

To Michelle’s “Felt Like Bothering Buddy” Problem

Make mentoring explicit job responsibility.

Not volunteer work. Not “in addition to your regular job.”

Reduce mentor’s other work during onboarding period (explicit trade-off).

Celebrate good mentoring publicly (status reward).

The Cost-Benefit

Mentor loses 20% productivity for 4 weeks.

New hire gains 40% faster ramp (productive 2-3 weeks earlier).

ROI positive by week 8-10.

Doesn’t Work for Everyone

Senior hires hate it.
They want autonomy, not hand-holding.

Works best for mid-level and below.

To Michelle’s 200-Page Wiki Problem

Wiki is reference, not curriculum.

Apprenticeship provides the learning path through the wiki.

“Just-in-time” learning (read docs when you need them for task) vs “just-in-case” (read everything upfront).

Suggestion

Pilot with next 2-3 hires. Measure:

• Time to productivity
• 90-day retention
• Mentor satisfaction
• New hire satisfaction

If it works, scale it.

[vp_eng_keisha]

Luis and Maya both have good solutions. I want to add the structure layer that makes either approach work.

The Problem Michelle’s Describing

Information overload + lack of path.

200-page wiki = “drink from the firehose”

New hire doesn’t know:

• What to read first
• What’s critical vs optional
• What success looks like each week

Our Approach: Onboarding Curriculum (Not Wiki)

Week-by-week structured learning path.

Week 1: Culture and Team

Focus: Who we are, how we work

• Meet entire team (sync, 30 min each)
• Read culture doc (async, 1 hour)
• Attend team meeting (sync observe)
• Ship something tiny (PR with 5-line change)

Success metric: Can name everyone, know team norms, tasted success

Week 2: Product and Codebase

Focus: What we build

• Product overview (sync with PM, 1 hour)
• Architecture walkthrough (sync with tech lead, 1 hour)
• Read key architecture docs (async, assigned reading)
• Fix your second bug (hands-on learning)

Success metric: Understand product, navigate codebase, ship independently

Week 3: Systems and Tools

Focus: How we operate

• Observability training (sync, 1 hour)
• Deploy process hands-on (pair with SRE)
• On-call shadowing (if applicable)
• Ship your first real feature (small, end-to-end)

Success metric: Can deploy, debug production, operate systems

Week 4: Autonomy

Focus: Independent contribution

• Own a feature end-to-end (solo)
• Present in team demo (practice communication)
• Get feedback, iterate
• Ship independently

Success metric: Full team member, no training wheels

Why Structure Helps

Reduces decision paralysis:
“What should I learn today?” is answered.

Builds confidence incrementally:
Small win → Medium win → Big win

Mixes sync and async intentionally:
Not “all async” or “all sync,” but right mode for right learning

Clear milestones:
Know when you’re on track vs falling behind

To Luis’s “Onboarding Exception” Approach

Yes, and structure makes the exception time-boxed and predictable.

Managers know what to schedule. New hires know what to expect.

To Maya’s Apprenticeship Model

Structure is “what” to learn. Apprenticeship is “how.”

Combine them:

• Week 1-2: Apprenticeship (heavy mentorship)
• Week 3-4: Structured solo work (lighter touch)

Implementation

• Notion template for each week
• Checkboxes for completion (satisfying!)
• Manager reviews progress weekly (15-min check-in)
• Adjust pace based on individual (some faster, some slower)

Results at Our EdTech Company

Onboarding satisfaction:
6.8/10 → 8.4/10

Time to first feature:
6 weeks → 3.5 weeks

90-day retention:
88% → 96%

To Michelle

Try combining:

• Structure (curriculum) - Keisha’s approach
• Sync boost (first 30 days) - Luis’s approach
• Apprenticeship (mentorship) - Maya’s approach

All three together addresses: information overload, isolation, tacit knowledge gap.

Not one silver bullet. Multi-layered solution for multi-faceted problem.

[product_david]

From product side: Cohort-based onboarding solves the “felt alone” problem Michelle mentioned.

Michelle Said Cohorts Don’t Scale - I Disagree

Individual onboarding:
Isolating, slow, inconsistent quality

Cohort onboarding (2-4 new hires start same week):
Peer support, faster learning, better culture transmission

How It Works

Hire in batches (quarterly or monthly, depending on growth rate)

Cohort goes through onboarding together:

• Shared Slack channel (#cohort-q1-2026)
• Weekly cohort sync (compare notes, support each other)
• Cohort graduates together (symbolic celebration)

Why This Helps Async Onboarding

New hires ask each other “stupid questions”:
Psychological safety. Peers judge less than seniors.

Learn together:
Collaborative vs isolated. “Did you figure out how to run tests locally?” “Yeah, here’s how.”

Build relationships with peers:
Not just senior mentors. Horizontal connections matter.

Cohort channel becomes safe space:
Admit confusion without feeling like you’re failing.

To Michelle’s “Doesn’t Scale” Concern

Actually scales better than 1:1 onboarding.

One mentor can support cohort of 3-4 (vs 1).

Shared learning sessions (vs repeated 1:1 explanations).

Cohort teaches each other (distributed learning load).

The Structure

Day 1: Cohort kick-off (sync, 1 hour)

• Meet your cohort peers
• Overview of 4-week plan
• Set expectations

Week 1-4: Shared onboarding tasks (async, but together)

• Everyone doing same learning path (Keisha’s curriculum idea)
• Help each other in cohort channel

Weekly cohort retro (sync, 30 min)

• “What went well this week?”
• “What’s confusing?”
• “What help do we need?”

Week 4: Cohort graduation demo (sync, 1 hour)

• Each person presents first feature
• Team celebrates
• Official “you’re ramped” moment

Challenges

Requires hiring pipeline discipline:
Batch hiring instead of continuous flow.

Doesn’t work for very small teams:
Need critical mass (at least 2-3 new hires per batch).

Timezone coordination harder:
Cohort across 3 timezones is tough. Try to cluster geographically.

Results I’ve Seen

Cohort members ramp 25% faster than solo onboarding.

Stronger peer relationships:
Cross-team collaboration later (they already know each other).

New hire satisfaction higher:
8.6/10 vs 7.1/10 for individual onboarding.

Suggestion to Michelle

Even if you can’t do full cohort model, create peer connections.

• Introduce recent hires (hired 3 months ago) to brand new hires
• “Alumni of onboarding” help current class
• Buddy system with cohort flavor (2-3 new hires paired with 2-3 mentors)

The peer support is the secret ingredient async onboarding is missing.