"Async-First" Doesn't Mean "Async-Only" - But How Do You Decide What Actually Needs a Meeting?

[maya_builds]

I want to push back on the async absolutism I’m seeing. Coming from design, I think we’re missing something important.

The Problem with Async Orthodoxy

“Async-first” is turning into “async-always” and some things genuinely work better synchronous.

I work with engineering teams that are hardcore async-first. And I watch them waste more time trying to force async than if they’d just jumped on a 30-minute call.

Things That Genuinely Work Better Sync

1. Brainstorming and ideation
Tried async brainstorming (Miro, FigJam). It feels flat. Real-time riffing generates 3x more creative ideas.

2. Conflict resolution
Text escalates tension. Video de-escalates. I’ve seen heated Slack threads resolve in 10 minutes on Zoom.

3. Complex technical explanations
Whiteboarding >>> Slack essays. Some things need visual, interactive discussion.

4. Relationship building
Especially across cultures. You can’t build trust purely async.

5. Onboarding and mentorship
Junior folks need real-time interaction to learn tacit knowledge.

Things That Should Stay Async

• Status updates
• Decision documentation
• Code review
• Most planning
• Broadcasting information

The Gray Area (Where People Fight)

• Architecture discussions
• Sprint planning
• Design reviews
• Incident post-mortems

My Framework for Deciding

Ask these questions:

1. Are we creating something new, or reviewing something existing?
   Creating = sync helps. Reviewing = async works.

2. Is there conflict or strong disagreement?
   Conflict = sync. Agreement = async.

3. Is visual/spatial thinking required?
   Visual = sync (whiteboard, diagrams). Verbal = can be async.

4. Is this time-sensitive?
   Urgency ≠ requires sync. Importance = maybe sync.

Real Example: Design System Color Palette

Tried async:

• 73 Slack messages over 2 weeks
• No decision (everyone had opinions, no convergence)

Called sync meeting:

• 45 minutes
• Decision made
• Everyone aligned

Why sync worked:
Visual discussion. Subjective preferences. Needed to see each other’s reactions to options. Couldn’t do that via text.

The Permission Structure I Use

Anyone can call a sync meeting, but must justify why async won’t work.

“This could have been an async doc” is valid feedback.

Meeting notes posted immediately after (for those who couldn’t attend).

To the “Timezone Coordination is Hard” Crowd

Yes. But some things are worth the coordination cost.

Strategies:

• Record the meeting for other timezones
• Rotate meeting times to share the pain
• Async prep + sync decision + async documentation

Questions for the Community

1. What criteria do you use for sync vs async?

2. How do you prevent “async-first” from becoming religious dogma?

3. Are there good tools for hybrid? (Async prep, sync decision, async follow-up)

I’m worried we’re optimizing for efficiency at the cost of effectiveness. Sometimes slower is better.

[product_david]

Maya, I love your framework. Let me add a product lens: Eisenhower Matrix adapted for sync vs async.

Four Quadrants

Urgent + High Stakes = Sync Required

• Incident response
• Critical product decision with customer deadline
• Example: Customer threatening to churn due to bug

Not Urgent + High Stakes = Async prep, optional sync discussion

• Strategy decisions
• Architecture changes
• Example: Choosing database for new service (async RFC + optional sync deep-dive)

Urgent + Low Stakes = Async with quick turnaround

• Minor bug prioritization
• Copy changes for marketing
• Example: Fixing button color before launch (async, but 4-hour SLA)

Not Urgent + Low Stakes = Async only

• Nice-to-have features
• Process tweaks
• Example: Improving internal dashboard (async doc, implement when convenient)

Why This Works

Makes sync/async decision objective, not based on who yells loudest.

“High stakes” is clear criteria:

• Affects revenue
• Affects customer experience
• Can’t be easily reversed

“Urgent” is time-bound:

• Needs decision in <24 hours = urgent
• “I want answer today” ≠ urgent
• “Customer cancels tomorrow without answer” = urgent

Examples from My Product Team

Pricing change for enterprise tier:
High stakes, not urgent → Async RFC with 1-week comment period + optional sync discussion

Customer churning due to critical bug:
High stakes, urgent → Sync war room, all hands

Icon color in new UI:
Low stakes, not urgent → Async Figma comment thread

Marketing copy for launch tomorrow:
Low stakes, urgent → Async Slack with fast response expectation

To Maya’s “Brainstorming Needs Sync” Point

Partially agree. Here’s my refinement:

Divergent thinking (generating ideas): Sync helps
Convergent thinking (choosing best idea): Async works

My process:

1. Async idea generation - Everyone contributes ideas in doc over 2 days
2. Sync shortlisting - 30-minute call to rapid-fire debate top ideas
3. Async decision doc - DRI decides with full context, posts reasoning

Gets benefits of both.

The Cultural Challenge

People mark everything “urgent” to force sync meetings.

Had to get strict: “I want an answer today” ≠ urgent.

“Customer cancels tomorrow without answer” = urgent.

Suggestion to Maya

Document your framework as decision tree.

Makes it easier for teams to self-serve the sync/async decision without constant meta-discussions about whether to have a meeting.

[vp_eng_keisha]

Important addition to Maya and David’s frameworks: Culture and personality matter more than you think.

What They’re Both Missing

Sync vs async preference varies by:

• Culture (national and company)
• Personality (introvert vs extrovert)
• Language fluency (native speakers vs ESL)

Cultural Differences I’ve Seen

US tech culture:
Over-indexes on efficiency. “Why are we having this meeting? This could be a doc.”

European engineers:
Value relationship first. “Why are we only using Slack? We should talk.”

Asian engineers:
Split, depends on company culture they came from. But often more comfortable with async (avoids real-time language barriers).

It’s not just national culture—it’s personality:

Introverts: Often prefer async (time to think, craft responses)
Extroverts: Often prefer sync (think out loud, energy from interaction)

Neither is wrong. Both need accommodation.

The Inclusion Problem with “Async-First”

Async privileges:

• Native English speakers (written communication is easier)
• People with quiet home environments (can write uninterrupted)
• People without caregiving responsibilities (can respond async anytime)

Video calls allow:

• Tone, body language, real-time clarification
• Shared screen for visual context
• More equitable for ESL speakers (speaking is easier than writing)

The Inclusion Problem with “Sync-First”

Sync excludes:

• People in minority timezones (always inconvenient hours)
• People with caregiving responsibilities (can’t do 8pm calls)
• Deep thinkers (need time to process, not rapid-fire)

My Approach: “Flexible First” Instead of “Async-First”

Default to async, but make sync easy when needed.

Rotate meeting times to share timezone pain (this week 8am Pacific, next week 5pm Pacific).

Record everything, whether async or sync.

Multiple participation paths:

• Attend live
• Watch recording
• Read written summary
• Contribute via async comments

Add to Maya’s Decision Framework

“Who’s affected by this decision?”

If decision affects someone who struggles with async (language barriers, writing skills), consider sync.

If decision affects someone in minority timezone, lean async.

To David’s Eisenhower Matrix

Good, but add third dimension: Inclusivity.

Some low-stakes decisions still need sync for relationship building:

• Early team formation: Over-index on sync (build trust first)
• Mature team: Over-index on async (execution mode)

The Meta Question

Are we optimizing for efficiency or effectiveness?

Efficiency = async wins every time.
Effectiveness = depends on context.

Sometimes slower is better. Sometimes the “overhead” of a sync call is the value (relationship, alignment, trust).

[eng_director_luis]

I’m going to add something potentially controversial: Meeting cost calculator.

Makes the abstract cost of sync meetings concrete.

How It Works

Slack bot that calculates literal dollar cost when you schedule a meeting.

Formula:
(# of attendees) × (average hourly rate) × (meeting duration + 15 min context switching)

Posts cost publicly: “This meeting will cost $2,400 in team time.”

Why This Works

Makes people think twice before scheduling.

Examples:

• 30-minute meeting with 8 people = $1,200
• 1-hour all-hands with 40 people = $12,000
• Weekly recurring 30-min standup with 6 people = $1,200/week = $62K/year

Is it worth it?

Behavior Changes We Saw

Meeting duration:
Default changed from 60 min → 30 min

Meeting attendees:
10 people invited → 5 people (only essential)

Meeting frequency:
3x per week → 1x per week (consolidated agendas)

Optional attendee acceptance rate:
80% → 40% (people opt out when not critical)

The Controversial Part: Timezone Penalty Multiplier

Meeting at 8am or 8pm (outside normal hours) = 1.5x cost.

Makes timezone pain visible in dollars.

Forces the question: Is this sync meeting worth making someone in Dublin wake up at 6am?

To Maya’s “What Actually Needs a Meeting?” Question

If cost is >,000, must justify why async won’t work.

We literally make people write in meeting invite: “Why async won’t work for this: [reason]”

CFO now asks me quarterly: “Why is engineering spending $40K/month on meetings?”

Forces prioritization.

To David’s Eisenhower Matrix

Cost is the tiebreaker.

High stakes + low urgency + high cost → default async unless cost-justified.

The Pushback We Got

“You’re reducing collaboration to dollars!”
Yes. And our budget is finite.

“Some things are worth the cost!”
Agreed. But which things? That’s the question.

“This feels cynical.”
Maybe. But it makes trade-offs explicit instead of invisible.

Results After 1 Year

• 40% reduction in meeting hours company-wide
• More intentional sync time (higher quality discussions)
• Engineers have more flow time for deep work
• Quarterly meeting budget visible to exec team

The Question I’m Asking You All

Is this too cynical?

Or is explicit cost awareness healthy for distributed teams where sync time is genuinely expensive (timezone coordination, flow disruption)?

I genuinely don’t know. But the data says it’s working.