We Hired 8 Engineers Last Year. 6 of Them Struggle With Async Communication. Is This the New Skills Gap?

General
1

I need to talk about something I’ve been noticing on my design systems team, and I’m curious if others are seeing this too.

We hired 8 engineers last year. 6 of them struggle with async communication. Is this the new skills gap we’re not talking about?

The Pattern I’m Seeing

These are smart, technically capable engineers. They can write clean code, understand complex systems, and ship features.

But their async communication is… rough.

Specific examples:

Vague Slack messages:

  • Them: “Build failed”
  • Me (internally screaming): Which build? Which branch? What’s the error? What have you tried?

Missing context:

  • They post a question in Slack
  • No link to the code
  • No description of what they’ve tried
  • No indication of urgency or timeline
  • They expect someone to drop everything and debug with them in real-time

Poor documentation:

  • PRs with no description or just “fix bug”
  • Design decisions with no rationale documented
  • Handoff docs that say “ask me if you have questions” instead of documenting the questions

Immediate response expectation:

  • They DM me at 3pm with “quick question”
  • When I respond 2 hours later (because I was in deep work), they’ve already asked 3 other people
  • Creates duplicate work and fragments knowledge

This Isn’t About Writing Ability

These engineers can write. Their code comments are fine. Their technical writing in PRs (when they remember to do it) is clear.

The issue is understanding async communication as a distinct skill:

  • Providing sufficient context upfront
  • Anticipating what information the reader will need
  • Respecting other people’s time and attention
  • Thinking through the problem before asking for help

The Impact on the Team

This isn’t just annoying—it’s expensive:

  • Projects stall because questions lack context and require 3 rounds of clarification
  • Knowledge gets lost because decisions aren’t documented
  • Senior engineers become bottlenecks answering the same clarifying questions over and over
  • Remote collaboration breaks down because timezone-distributed teammates can’t help without sufficient context

Research shows that poorly structured remote teams spend 33% more time on coordination. I think async communication skills are a huge part of that gap.

Where’s the Training?

My hypothesis: Most CS programs and bootcamps don’t teach async communication.

They teach algorithms, data structures, system design. Maybe some technical writing. But not:

  • How to ask a good question in a distributed team
  • How to document a decision so future-you (or future-teammate) understands it
  • How to provide context in a Slack message or PR description
  • How to structure information for async consumption

We’re hiring people into async-first environments without teaching them the communication protocols.

What We’re Doing About It

We’re creating an “async communication onboarding” module for new hires:

  1. Templates for common scenarios:

    • Bug reports (include: what broke, expected behavior, actual behavior, steps to reproduce, what you’ve tried)
    • Feature proposals (include: problem statement, user impact, proposed solution, alternatives considered, open questions)
    • Technical questions (include: goal, context, what you’ve tried, specific question)

  2. Communication examples library:

    • Side-by-side comparisons: “Weak async message” vs “Strong async message”
    • Real examples from our team (anonymized)

  3. Feedback loops:

    • In code reviews, we also review PR descriptions
    • In Slack, we model good responses: “Hey, can you add [specific context] so I can help?”

The Bigger Question

Should we be hiring for async communication explicitly?

Right now our job descriptions list: “Strong communication skills”

But that’s too vague. Should we say:

  • “Experience working in remote/distributed teams”
  • “Demonstrated ability to document technical decisions”
  • “Comfortable with async-first collaboration tools”

Or do we assess it in interviews? (How would you even test for this?)

I don’t have the answers, but I think this is a real skills gap that’s only going to get more important as remote work becomes standard.

What are you all seeing? Is this just my team, or is async communication the skill we’re not training for?

2

Maya, I’m seeing the exact same pattern on our fintech engineering teams. This is not unique to you.

Junior Engineers Especially Struggle

The context-free Slack messages are my biggest frustration:

What we get:
“Build failed”

What we need:
“Build failed on staging for order-api service. Error logs show timeout connecting to Redis at 2:34pm PT. I checked Redis health—it’s up. Suspecting network config change from this morning’s infra update. Looking at firewall rules now but wanted to flag in case anyone else is seeing timeouts.”

The difference? The second version gives me:

  • What broke (order-api, not the entire platform)
  • Where (staging environment)
  • When (2:34pm PT)
  • Context (after infra update)
  • What they’ve tried (checked Redis health)
  • Their hypothesis (network config)
  • Current action (investigating firewall rules)

The first version forces me to ask 6 follow-up questions.

We’re Now Assessing This in Interviews

We added an explicit “async communication” assessment to our interview process:

The Exercise:

We show candidates a vague bug report:

“Login isn’t working. Urgent. Please fix.”

Then ask them to:

  1. Rewrite this bug report with all the information you’d need to investigate it
  2. List the questions you’d ask the reporter

This reveals:

  • Do they think about context and reproduction steps?
  • Do they understand what “enough information” looks like?
  • Can they communicate technical concepts clearly?

Top candidates immediately ask: Which environment? Which user? What error message? What happens when you try to login? When did this start?

Weak candidates struggle to think beyond “I’d need to see the logs.”

The Template Solution

Your templates idea is exactly what we need. We’ve standardized on:

For bug reports:

### What broke
### Expected behavior  
### Actual behavior
### Steps to reproduce
### What I've tried so far
### Environment details (browser, OS, etc.)

For architecture decisions:

### Problem statement
### Constraints
### Options considered (with pros/cons)
### Recommendation + rationale
### Open questions / risks

These templates train muscle memory. After 2-3 months, people internalize the structure.

The Question for You

Maya, have you found any good ways to measure improvement in async communication skills?

We’re treating it as a core competency, but it’s hard to put metrics on “better Slack messages.”

Thinking about tracking:

  • Time-to-resolution for questions (fewer clarifying rounds = better initial message)
  • PR approval speed (better descriptions = faster reviews)
  • “Good documentation” callouts in retros

But these are all proxies. Any better ideas?

3

This hits close to home. The async communication gap affects cross-functional collaboration massively, not just engineering-to-engineering.

The Product-Engineering Impact

When engineers can’t communicate async effectively, it creates blockers for product and design:

Classic scenario:

  • I write a product spec with requirements
  • Engineer posts in Slack: “Unclear on the pricing logic”
  • I respond: “Which part?”
  • 6 hours pass
  • They respond: “The discount calculation”
  • I respond: “What specifically about it?”
  • 4 hours pass
  • They respond: “How do we handle edge cases?”
  • Me: “Which edge cases?”

By this point, it’s been 2 days and we still haven’t gotten to the actual question.

Better version:

“Re: pricing logic in the spec, section 3.2. For the volume discount calculation, I see we apply 10% for orders >$1000. Three edge cases aren’t covered: 1) Multiple items totaling >$1000 (apply discount per item or total?), 2) Refunds that drop order below $1000 (reverse discount?), 3) Promo codes + volume discounts (stack or take max?). What’s the intended behavior for each?”

One message. I can respond with complete answers. Work proceeds.

The Cost of Vague Requirements (On Us Too)

Here’s the uncomfortable part: Product managers are also terrible at async communication.

We write vague requirements:

  • “Make the checkout flow faster”
  • “Improve the search experience”
  • “Add social login”

Then we get frustrated when engineers ask clarifying questions.

If I’m honest, I’m expecting them to read my mind or hop on a call so I can explain what I “really meant.”

That’s not async-first. That’s lazy spec writing.

The Solution: Templates for Everyone

Maya, your template idea should extend beyond engineering. We need:

Product requirement templates:

  • Problem statement (what user pain are we solving?)
  • Success metrics (how do we measure if this worked?)
  • User stories (who needs this, and why?)
  • Technical constraints (what are the boundaries?)
  • Open questions (what do we need to decide?)

Design handoff templates:

  • User flows (annotated)
  • Edge cases and error states
  • Mobile vs desktop variations
  • Accessibility requirements
  • Assets and resources

When product and design provide complete context upfront, engineering can work async. When we’re vague, we force sync clarification loops.

Interview Screening

Luis, your interview assessment is brilliant. We should adopt that.

I’d add: Give candidates a vague PRD and ask them to identify what’s missing.

Example PRD:

“We need a dashboard for users to see their account activity. Make it intuitive and fast.”

Strong candidates will flag:

  • “What’s ‘account activity’? Transactions? Logins? Both?”
  • “How far back? Last 30 days? All time? Configurable?”
  • “Fast” = page load? Query time? What’s the target?
  • What’s the core action we expect users to take from this dashboard?

This tests whether they think in terms of crisp requirements vs. ambiguous hand-waving.

The async communication gap is a two-way street. Engineering needs better question-asking; product needs better spec-writing.

4

You’re onto something critically important, Maya. This is a real skills gap, and it’s one we need to address at the organizational level.

Async Communication = Senior Engineer Leverage

Here’s what’s actually happening: Async communication is how senior engineers scale their impact.

When I was at Microsoft, this was explicitly taught. Senior engineers were expected to:

  • Write design docs that could be understood without explanation
  • Provide PR feedback that was actionable without a follow-up meeting
  • Answer questions in a way that taught the underlying principle, not just the immediate answer

At startups? This is assumed, not taught. People are thrown into distributed teams and expected to figure it out.

The Three-Part Framework

For structured async communication, we teach a simple model: Context, Action, Impact (CAI)

Context: What’s the situation?
Action: What needs to happen?
Impact: Why does it matter?

Applied to Maya’s “Build failed” example:

Weak:

“Build failed”

Strong (CAI):

Context: Staging deploy for user-service failed at 2:34pm PT after merging PR #847
Action: Error shows dependency conflict with auth-lib v2.3. Need to update our package.json to use ^2.3 instead of ^2.1
Impact: Blocking staging environment for QA testing scheduled tomorrow morning

CAI forces people to think through: What does my reader need to know to take action?

Make It Part of Performance Reviews

We’ve integrated async communication into our engineering ladder:

Junior (L3): Uses templates for bug reports and questions
Mid (L4): Writes clear PR descriptions and documents decisions
Senior (L5): Produces documentation that onboards new team members
Staff (L6): Sets communication standards and trains others

It’s not a “nice to have”—it’s a promotion criterion.

If someone can’t communicate async effectively, they can’t reach senior+ levels on distributed teams. Full stop.

Resource Recommendation

GitLab’s async communication handbook is the gold standard.

Required reading for all new hires at my company. It covers:

  • How to structure written updates
  • When to use sync vs async
  • Documentation best practices
  • Time zone collaboration etiquette

The Training Gap You Identified

Maya, you’re right that CS programs don’t teach this. But here’s the thing: Most companies don’t teach it either.

We expect engineers to learn by osmosis, which means:

  • People mimic whatever communication patterns they observe
  • If the team has bad async habits, new hires learn bad async habits
  • Without explicit training, improvement is random

We need to treat async communication like any other technical skill: teach it, practice it, give feedback, measure growth.

The question isn’t whether this is important. The question is: Are we going to explicitly train for it, or keep pretending it’s something people should “just know”?

5

Maya, this is both a hiring problem and a development opportunity. We can fix this, but it requires systematic intervention.

Treating Async as a Core Competency

At our EdTech company, we’ve started treating async communication as a core engineering competency, just like code quality or system design.

Why? Because in a distributed team of 80+ engineers:

  • Poor async communication creates exponential coordination overhead
  • Senior engineers’ time is the most valuable resource—bottlenecking them with clarifying questions is expensive
  • Timezone collaboration completely breaks without strong async skills

Practical Development Approach

Michelle’s CAI framework is excellent. We’ve implemented something similar with mentorship pairing:

The Model:

  • Pair each junior/mid engineer with a “strong async communicator” for 3 months
  • Junior observes how senior structures questions, writes docs, responds to issues
  • Senior provides real-time feedback: “Your question lacked context. Here’s how I’d rewrite it…”
  • Crucially: This is explicit. We tell people “You’re learning async communication” (not just “debugging together”)

After 3 months, measurable improvement.

The Feedback Loop Problem

One reason people don’t improve: They never get feedback on their async communication.

Think about it:

  • If you write bad code, PR reviews catch it
  • If you design a bad system, architecture review catches it
  • If you send a context-free Slack message… someone just asks clarifying questions, and you move on

No feedback loop = no learning.

Our fix: We’ve normalized giving communication feedback:

  • “Hey, this question would be easier to answer with [specific context]. Can you add that?”
  • In retros, we celebrate examples of excellent async communication
  • We created “async excellence” awards (lightweight recognition)

Make good async communication visible and valued.

The Job Description Question

You asked if we should explicitly list “async communication” in job descriptions. Yes. Absolutely.

Our current postings include:

  • “Experience collaborating on distributed/remote teams”
  • “Strong written communication and documentation skills”
  • “Comfortable with async-first workflows and tools (Slack, Notion, etc.)”

In interviews, we ask:

  • “Describe a time you had to solve a problem with teammates in different timezones”
  • “How do you typically communicate a complex technical decision to your team?”

Answers reveal: Do they think about documentation? Do they consider the reader’s perspective? Do they understand async collaboration?

The Long Game

Engineers who master async communication become force multipliers. They:

  • Unblock teammates across timezones
  • Document decisions that future team members can reference
  • Scale their impact beyond what they can personally build

This isn’t a “nice to have” soft skill. It’s a technical leadership requirement.

The companies that explicitly train for this will have a massive advantage in distributed work environments.

Maya, your observation isn’t just about your team—it’s a systemic gap in how we prepare engineers for modern work. The question is: Who’s going to close it?