Async-First Works Great For Existing Teams. But How Do You Onboard New Engineers Without Real-Time Interaction?

General
1

We’re scaling our EdTech engineering team from 25 to 80+ engineers in a fully remote-first environment. Async-first workflows have been incredible for team productivity.

But here’s the paradox: Async-first works great for existing teams, but it makes onboarding new engineers harder.

The Data Tells the Story

Before async-first transition:

  • Average time-to-first-PR: 2 weeks
  • New hire satisfaction (first 30 days): 4.2/5
  • Onboarding completion rate: 95%

After going async-first:

  • Time-to-first-PR: 4 weeks (doubled)
  • New hire satisfaction: 3.1/5 (significant drop)
  • Onboarding completion rate: 78%

Something broke. And it makes sense when you think about it.

Why Async-First Is Hard for New Hires

New team members need:

  • Context: Understanding team norms, technical decisions, cultural patterns
  • Relationship building: Knowing who to ask for what, building trust
  • Real-time guidance: Quick clarification when stuck, validation they’re on the right track

All of these are harder in async environments:

  • Context is scattered across Notion docs, Slack history, GitHub ADRs—overwhelming
  • Relationship building requires intentional effort, not casual office interactions
  • Real-time guidance feels scarce when everyone’s in deep work with Slack on DND

The result: New hires feel isolated and unsupported.

One engineer told me in their exit interview (yes, they left after 6 weeks):

“I felt like I was constantly shouting into the void. I’d post questions in Slack and wait hours for responses. I never knew if I was doing things right until someone finally reviewed my PR 3 days later. It felt lonely and chaotic.”

That hurt to hear. But it was honest feedback about what we’d broken.

Three Approaches We Tried

Attempt 1: Sync-Heavy First 2 Weeks

Approach:

  • Daily 1:1s with manager for first 2 weeks
  • Multiple “meet the team” video calls
  • Synchronous pairing sessions
  • Real-time Q&A encouraged

Result:

  • Time-to-first-PR improved back to 2 weeks :white_check_mark:
  • But: Doesn’t scale (manager bandwidth bottleneck)
  • And: Created two cultures—sync for new people, async for everyone else

We couldn’t sustain this as we hired more people.

Attempt 2: Pure Async with Detailed Docs

Approach:

  • Comprehensive onboarding documentation in Notion
  • Step-by-step guides for setup, workflows, norms
  • Pre-recorded Loom videos: “How we work,” “Tech stack overview,” “Team rituals”
  • Async-first from day 1

Result:

  • New hires felt lost and isolated :disappointed_face:
  • They’d read the docs but have no one to ask clarifying questions
  • Couldn’t distinguish important information from nice-to-know details
  • Time-to-first-PR stayed at 4 weeks
  • New hire satisfaction stayed low

Documentation alone wasn’t enough.

Attempt 3: Hybrid—Async Default with Structured Sync Touchpoints

Approach:

  • Async default: Comprehensive docs, pre-recorded videos, async-first communication norms
  • Structured sync touchpoints:
    • Daily 15-minute check-ins for first month (manager or buddy)
    • Weekly 1-hour pairing sessions with senior engineers
    • Bi-weekly “new hire cohort” calls (if we have multiple people starting around the same time)
    • Monthly “office hours” with CTO/VPs

The key: Sync time is structured and intentional, not ad-hoc availability.

Result:

  • Time-to-first-PR: 2.5 weeks (back to acceptable) :white_check_mark:
  • New hire satisfaction: 3.9/5 (much better) :white_check_mark:
  • Better async communication from new hires (they learn by observing structured examples)

This is our current model, and it’s working better.

The Breakthrough: Video Library + Live Q&A

One thing that really helped: Recorded “How We Work” video library + live Q&A sessions.

The Video Library:

Pre-recorded Looms covering:

  • “How we use Slack” (threading norms, channel purposes, response expectations)
  • “How we do code review” (PR standards, review etiquette)
  • “How we make decisions” (RFC process, when to use sync vs async)
  • “How we document” (where things live, what to write down)
  • “How we handle incidents” (on-call rotation, escalation)

New hires watch these async at their own pace.

The Live Q&A:

Weekly 30-minute “Onboarding Office Hours”

  • Any new hire (first 90 days) can join
  • Open Q&A format: “Ask us anything about how we work”
  • Recorded and added to the video library

This combo gives both: self-paced learning + human connection.

What We’re Still Struggling With

Building social connections and psychological safety in async-first.

In sync-heavy cultures, you build trust through:

  • Debugging together at midnight
  • Casual Slack banter
  • Virtual coffee chats
  • Team social events

In async-first, these feel… forced? Optional? People skip them because they’re “not real work.”

We’re trying:

  • Random pairing for 20-min virtual coffee (opt-out, not opt-in)
  • Team retros that are half sync / half async
  • Celebrating async communication excellence in all-hands
  • Explicit discussion of team norms and psychological safety

But I’m not convinced we’ve cracked this yet.

The Open Question

Is there a fundamental trade-off between async efficiency and onboarding effectiveness?

Put differently: The very things that make async-first productive for established teams—documentation over discussion, written over verbal, async over sync—make it harder for new people to learn the tacit knowledge, build relationships, and feel connected.

Maybe we accept this trade-off. We optimize for long-term team velocity, accepting higher onboarding friction.

Or maybe there’s a better model we haven’t found yet.

For those running remote-first teams: How are you onboarding new engineers in async-first environments? Have you solved the psychological safety and connection challenge?

2

Keisha, I feel this. I joined my current company right as they were transitioning to async-first, and the isolation was real.

The New Hire Experience of Async-First

From the inside, here’s what it felt like:

Week 1:

  • Got a massive Notion workspace with “everything you need to know”
  • 50+ docs, pre-recorded videos, Slack channels everywhere
  • No idea what was important vs. nice-to-have
  • Felt like drinking from a firehose, alone

Week 2:

  • Started trying to contribute
  • Posted questions in Slack: No response for 6 hours
  • Unclear if my question was stupid, if I posted in the wrong channel, or if people were just busy
  • Started doubting if I was cut out for this

Week 3:

  • Finally got assigned an “onboarding buddy” (should have happened Week 1)
  • Buddy explained the unwritten norms: “Oh, that channel is dead, post here instead” and “When you tag someone, they’ll usually respond within 2 hours”
  • Suddenly everything made more sense

The breakthrough for me: Having a human guide through the async landscape.

What Actually Helped

Your “Approach 3” is almost exactly what saved my onboarding:

1. Onboarding buddy (explicit, not implicit)

  • Assigned day 1, not week 3
  • Clear role: “This person answers your ‘dumb questions’ without judgment”
  • Weekly 30-min check-ins for first 2 months

2. Private “onboarding channel” for new hires

  • Normalized asking basic questions
  • Other new hires answered each other (peer support)
  • Senior people would jump in periodically with helpful context

Cultural norm we established: “No question is too basic in #onboarding”

This made it psychologically safe to ask things like:

  • “Where do I find the staging environment credentials?”
  • “What’s the difference between the #eng and #eng-general channels?”
  • “Is it okay to merge my own PR after 2 approvals, or do I need to wait?”

3. Recorded walkthroughs with real humans, not just docs

Seeing someone’s face explaining something made it feel less isolating than reading text.

The best onboarding videos weren’t polished—they were screen recordings of someone saying “Let me show you how we actually do code review” and walking through a real PR.

The Psychological Safety Challenge

You asked about this, and I don’t think we’ve solved it either.

The problem: In async-first, you can’t read the room.

  • Is my question annoying people? (No body language to tell)
  • Did my joke land or offend? (No immediate facial reactions)
  • Is my work good enough? (Days between posting and feedback)

What’s helped (a little):

  • Explicit positive feedback in public channels: “Great question!” “Love this approach”
  • Emoji reactions (seems small, but shows people are reading/engaging)
  • Occasional “behind-the-scenes” sync time just for relationship building (not work discussions)

But yeah, it’s still harder than in-person trust building.

Suggestion for Your Team

One thing I wish my company had done: “New hire shadows” for async workflows.

Like pair programming, but for async communication:

  • New hire observes how senior engineer structures a Slack question
  • Watches them write a PR description
  • Sees how they respond to an RFC

Then they try it themselves with feedback: “Here’s how I’d rewrite that to be clearer”

Explicit training on the medium, not just the content.

Keisha, your observation about the trade-off is spot-on. Async-first is optimized for experienced team members. New people need more hand-holding, and that’s okay to acknowledge.

3

Keisha, we’ve worked through this exact challenge on our fintech teams. Here’s our structured approach.

The 30-60-90 Day Onboarding Framework

We’ve implemented explicit phases with different sync/async balances:

First 30 Days: More Sync, Explicit Mentorship

Structure:

  • Daily 15-min check-ins with manager (as you’re doing)
  • Twice-weekly pairing sessions with assigned mentor (1-2 hours each)
  • Weekly team sync specifically for new hires to ask questions
  • Cohort onboarding when possible (5-10 new hires starting around the same time)

Why this works:

  • High touch during the most disorienting period
  • Multiple channels for questions (buddy, manager, cohort)
  • Real-time feedback on work builds confidence faster

Metrics: Time-to-first-commit, time-to-first-PR, new hire sentiment

Days 30-60: Transition to Async Default

Structure:

  • Check-ins reduce to 3x/week (MWF)
  • Pairing sessions reduce to weekly
  • Introduce explicit async practices:
    • “This week, post your questions in Slack before DMing me”
    • “Write up your approach before we pair on it”
  • Still maintain weekly team sync

Why this works:

  • Gradual reduction of sync support
  • Builds async muscle memory with a safety net still in place
  • Person starts internalizing team norms

Days 60-90: Full Async-First

Structure:

  • Check-ins reduce to weekly 1:1s (standard cadence)
  • Pairing is ad-hoc / on-demand
  • Expected to follow standard async-first workflows
  • Monthly “office hours” with senior leadership

Why this works:

  • Person is now productive independently
  • Has built relationships and knows who to ask for what
  • Comfortable with async communication norms

The key: We explicitly communicate the transition and why.

In week 4, manager says: “You’re doing great. Over the next month, we’re going to reduce check-ins as you ramp up. This is normal and means you’re on track.”

No surprises. No wondering “Did I do something wrong?”

Tactical Tool: The “New Hire Dashboard”

We created a living Notion dashboard that each cohort updates for the next:

Sections:

  • Week 1 Survival Guide (credentials, setup, first tasks)
  • Frequently Asked Questions (constantly updated by new hires as they discover gaps)
  • Who to Ask for What (directory of people and their areas)
  • Common Gotchas (things that confused previous new hires)
  • Async Communication Examples (good Slack questions, PR descriptions, RFC comments)

The cultural element: Each new hire is expected to add at least 3 things to the dashboard during their first 90 days.

This makes onboarding docs living and relevant, not stale and forgotten.

Cultural Norm: Record Loom Responses

For common new hire questions, we encourage people to record Loom responses:

Example:
New hire asks in Slack: “How do I run integration tests locally?”

Instead of typing a long response:

  1. Senior engineer records 3-min Loom: shows them on screen
  2. Posts Loom in response + adds it to onboarding docs
  3. Next new hire can watch the video instead of re-asking

This scales knowledge without requiring synchronous time.

Addressing the Psychological Safety Gap

Maya’s right—this is the hardest part.

What’s worked for us:

  • Public recognition of good questions: “Great question, adding this to onboarding docs”
  • Normalize vulnerability: Leaders share their own “I didn’t know this” stories
  • Dedicated social time: Monthly virtual game sessions, optional but encouraged
  • Random coffee chats: Automated pairing via Donut, 20 mins, casual

But I’ll be honest: Async-first will always have lower psychological safety than in-person for new people.

We accept this as a trade-off. We optimize for long-term distributed team effectiveness, knowing onboarding will be harder.

Keisha, your 3-attempt progression is exactly right. Hybrid with structured touchpoints is the answer. The 30-60-90 framework codifies that transition.

4

This is one of the hardest async-first challenges, and I think you’re asking the right question about trade-offs, Keisha.

The Documentation Quality Dependency

Here’s a systemic insight: Quality of documentation directly predicts onboarding success in async-first environments.

If existing team members struggle to find information, new hires have zero chance.

Litmus Test for Documentation Health:

Ask a mid-level engineer who’s been on the team 6+ months:

  • “Where would you find the API authentication flow documentation?”
  • “How do you know which services depend on the user service?”
  • “What’s the process for requesting AWS access?”

If they can’t answer immediately, your documentation isn’t good enough to onboard async-first.

New hires will experience 10x the friction.

Documentation as Engineering Investment

At our SaaS company, we treat documentation like technical debt:

We dedicate engineering time to onboarding documentation:

  • Each team budgets 5% of sprint capacity to documentation updates
  • “Improve onboarding docs” is a standing backlog item
  • Quarterly documentation reviews: “What’s missing? What’s outdated?”

This isn’t a “nice to have”—it’s a prerequisite for async-first onboarding.

The Social Connection Problem

You mentioned struggling with psychological safety and social connection. This is the unsolved problem of remote-first work.

Here’s my controversial take: Accept that async-first will always have longer onboarding and lower initial psychological safety.

In-person teams build trust through:

  • Shared physical space and casual encounters
  • Reading body language and social cues
  • Spontaneous collaboration and problem-solving

Remote async-first teams can’t replicate this. And that’s okay.

What we can do instead:

  • Be explicit about norms and expectations (what’s implicit in-person must be explicit remote)
  • Create structured opportunities for connection (not spontaneous, but intentional)
  • Measure and optimize for long-term team health, not just onboarding speed

Practical Tactics We Use:

1. Virtual coffee chats (mandate, don’t suggest)

  • Automated via Donut
  • Opt-out, not opt-in (default is you participate)
  • 20 minutes, casual, no agenda
  • Tracked as a team norm (if someone consistently opts out, manager asks why)

2. “Watercooler” Slack channel

  • Explicitly for non-work chat
  • Encouraged by leadership (I post random stuff there regularly)
  • Creates space for personality and connection

3. Team retrospectives with dedicated “connection” section

  • Not just “what went well / poorly”
  • Include: “How are you feeling?” “What’s energizing or draining you?”
  • Creates psychological safety by normalizing vulnerability

Metric We Track

“Time to independently complete first task”

Not just time-to-first-PR (which might be hand-held), but:

“When can this person take a well-defined task from the backlog and ship it independently, from spec to deployment?”

This measures true onboarding effectiveness in async-first.

Our targets:

  • 30 days for senior engineers
  • 45 days for mid-level
  • 60 days for junior

If we’re exceeding these, something’s broken in our onboarding or documentation.

Keisha, you’re not wrong that there’s a trade-off. The question is: Is the long-term productivity gain of async-first worth the higher onboarding friction?

For distributed teams, I think the answer is yes. But we have to be intentional about minimizing the onboarding cost.

5

Keisha, all three of you have nailed different parts of this. I want to add the cross-functional onboarding perspective.

Product Onboarding Has the Same Challenge

New PMs joining our company face the exact same async-first onboarding paradox:

What they need to learn:

  • Product context (why we built what we built)
  • Customer understanding (who are we serving, what problems do they have)
  • Team dynamics (who makes what decisions, how do we collaborate)
  • Business context (metrics, strategy, competitive landscape)

All of this is harder to learn async.

What We’ve Learned: Decision Log as Onboarding Tool

Luis mentioned the “New Hire Dashboard”—we have something similar for product called the “Decision Log”.

Structure:

  • Every significant product decision documented
  • Not just what we decided, but why
  • Alternatives considered
  • Data/research that informed the decision
  • Date and participants

For new PMs:

  • Assigned to read last 90 days of decisions (takes ~2 weeks)
  • Gives them product context without needing to ask “Why did we build X?”

This is way more efficient than:

  • Scheduling meetings with everyone to learn context
  • Asking the same questions existing team already discussed
  • Reinventing solutions to previously-solved problems

Architecture Decision Records (ADRs) for Engineering

Engineering has the same concept: ADRs document architectural decisions.

When new engineers ask “Why is our auth system designed this way?” → Point them to the ADR.

The pattern: Make historical context easily discoverable async.

Practical Tip: First Week “Scavenger Hunt”

We gamify learning the information architecture.

New hire onboarding includes a “scavenger hunt” of questions:

  • Where is the staging environment URL documented?
  • Find the decision log entry for why we chose PostgreSQL over MySQL
  • What’s the SLA for P1 incidents?
  • Who owns the payment processing service?
  • Where do we track customer feature requests?

All questions are answerable by exploring our docs, Notion, GitHub, etc.

Why this works:

  • Teaches them how to find information (more valuable than any specific fact)
  • Builds confidence in navigating the async knowledge base
  • Identifies documentation gaps (if they can’t find the answer, docs are incomplete)

After the scavenger hunt, they know how to self-serve information instead of asking people.

The Social Connection Insight

Michelle’s point about “this is an unsolved problem” is honest and important.

But here’s what I’ve noticed: The people who struggle most with async-first onboarding are those coming from in-person/sync-heavy environments.

Engineers starting their career remote-first seem to adapt faster. They don’t have the expectation of in-person social connection.

Hypothesis: As remote-first becomes more common, this problem naturally improves over time. The next generation of engineers won’t know anything different.

For now: We need to be explicit about what async-first means and set realistic expectations during hiring.

In our job descriptions, we now say:

“We’re a remote-first, async-first team. This means most communication happens in writing (Slack, Notion, GitHub). If you thrive on in-person collaboration and real-time interaction, this may not be the right environment.”

Better to filter for fit than struggle with mismatched expectations.

Final Thought

Keisha, your Approach 3 (hybrid with structured touchpoints) is the right model.

The meta-lesson: There’s no one-size-fits-all. Some people need more sync time during onboarding, others are fine async from day 1.

Give new hires agency:

  • “Here’s the default onboarding structure”
  • “If you need more check-ins, let me know”
  • “If you’re comfortable going async sooner, tell me and we’ll adjust”

Personalized onboarding > rigid frameworks.