The Case Against Meetings - When Async-First Goes Too Far?

[vp_eng_keisha]

We just crossed 80 engineers at our EdTech startup, and I need to share something I got wrong that nearly cost us our culture.

When I joined as VP Engineering 18 months ago, we had 25 engineers and too many meetings. Calendar tetris was killing productivity. I’d seen this problem at Google and Slack - the answer seemed obvious: go async-first. I read all the playbooks, brought in the consultants, and we went hard.

The wins were real. Within 6 months:

• 50% reduction in standing meetings
• Documentation quality skyrocketed
• Engineers reported 3+ hours more focused work daily
• Distributed hiring became possible (we’re now across 6 timezones)

I was feeling pretty good about myself. Then the cracks started showing.

Our junior engineers were struggling. Decision velocity slowed to a crawl. A critical architectural decision about our database sharding strategy sat in an async RFC thread for THREE WEEKS. People were adding comments but no one was driving to closure. Meanwhile, our competitor shipped a similar feature.

The breaking point was our Q3 engagement survey. Team cohesion scores dropped 40%. One senior engineer wrote: “I feel like I’m working alone with 79 strangers.”

I had optimized for efficiency and lost the human element.

Here’s what I learned: Async-first doesn’t mean async-only. We needed what I now call “Synchronous Moments That Matter” - a framework for when you override the async default.

Three categories where sync is non-negotiable:

1. Crisis Response - Production incidents, security issues, anything time-critical. Spinning up a Zoom is faster than a Slack thread when the site is down.

2. Complex Debates - Technical decisions with significant trade-offs need live discussion. Async threads spiral into misunderstanding. We now do: async RFC for context, 60-min sync debate with decision-makers, async approval process.

3. Team Building - This was my biggest blind spot. You can’t build trust asynchronously. We now protect 2 hours per week for “low-agenda collaboration” - demo days, retros, pair programming sessions, even just shooting the shit.

Everything else stays async. Code reviews, status updates, most planning, documentation. But these three categories get synchronous time, guilt-free.

We’re three months into this hybrid model. Team cohesion scores recovered. Decision velocity is back up. And ironically, we’re now at 45% fewer meetings than when we started - because we’re more intentional about which ones matter.

My question for this community: How do you balance async efficiency with the human connection that makes great teams? Where do you draw the line between “this can be async” and “we need to get in a room”?

I’m still figuring this out. Would love to hear what’s worked for you, and what’s failed spectacularly.

[eng_director_luis]

This resonates deeply, Keisha. I’m managing 40+ engineers across US and Latin America (Mexico City, São Paulo, Austin), and I made the exact same mistake.

We went 100% async about a year ago. Documentation improved, meeting fatigue disappeared - all the wins you described. But six months in, our attrition started climbing. Exit interviews revealed engineers felt disconnected, especially mid-level folks who weren’t senior enough to drive async decisions but weren’t junior enough to need constant mentorship.

The turning point for me was similar to yours: a critical decision about our payment processing architecture. We had an async RFC with 47 comments over two weeks. Every comment raised valid points, but no one wanted to make the final call asynchronously. The decision finally happened when I just scheduled a sync meeting - we resolved it in 90 minutes.

My solution has been “Sacred Sync Windows” - two hours on Tuesday and Thursday mornings (9-11am Central) when everyone is expected to be available for synchronous collaboration. That’s our overlap window that works for Mexico City through São Paulo.

Here’s what we use those windows for:

• Complex technical debates that need back-and-forth (exactly your category 2)
• Conflict resolution - you can’t resolve interpersonal tension asynchronously
• Brainstorming sessions - async ideation doesn’t have the same energy
• Team celebrations - shipping wins, birthdays, work anniversaries

Everything else remains async. Code reviews, status updates, most planning, documentation - all happens in our own time zones.

The results after 6 months: We’re at 35% fewer meetings than our original schedule (before we went 100% async), but we have the RIGHT meetings now. Engineers know exactly when they need to be present vs when they can work in flow state.

One thing I’d add to your framework: The cost of synchronous should be visible. I keep a spreadsheet showing how many people × hours each sync meeting consumes. When someone wants to schedule a new recurring meeting, I show them: “This is 24 person-hours per month. What async approach have we tried first?” It creates healthy friction.

Your “Synchronous Moments That Matter” framework is spot-on. The key is discipline - maintaining the async default while being intentional about those moments. Too many teams swing back to sync-first the moment they hit a bump.

[maya_builds]

Okay this whole thread is giving me flashbacks to our design team’s async experiment last year.

Here’s my hot take from the design side: Some work is fundamentally synchronous and we need to stop pretending otherwise.

Design reviews are the perfect example. I tried SO HARD to make them async. We recorded Loom walkthroughs, left detailed Figma comments, wrote design docs with all our reasoning. And you know what? The designs were worse.

Why? Because critique requires nuance. When someone says “this doesn’t feel right” in a meeting, you can probe: “What specifically? The hierarchy? The interaction model? The visual weight?” And you watch their face and you figure it out together.

In async comments, “this doesn’t feel right” just sits there. You respond with questions. They respond 6 hours later. Three days and 12 comments later you’re still not aligned, and the deadline passed.

But here’s the rub: Sync design reviews have a dark side too. They favor the loud voices. The confident people who speak up first often set the direction. Our quieter designers (who often have the best insights) get steamrolled.

Async comments are more equitable in that way. Everyone gets a voice, no one dominates.

So I’m stuck in this tension: Creative collaboration needs sync, but sync favors extroverts.

My current experiment (only 2 months in so take with salt): Rotating review times. We have three design review slots across the week:

• Monday 8am PT (terrible for SF, great for East Coast/Europe)
• Wednesday 2pm PT (perfect for Americas)
• Friday 5pm PT (awful for West Coast, decent for APAC)

Everyone experiences the timezone pain equally. No one gets their preferred slot every time, but no one is always suffering either.

Plus async comments are still welcome - we just use the sync time to resolve the complex stuff.

Not sure if it’s working yet. Ask me in 4 months.

Keisha, your framework makes me wonder: How do you handle the equity piece? Sync meetings inherently favor certain communication styles and timezones. How do you make sure your “Synchronous Moments That Matter” don’t accidentally exclude the people who do better async?

[mobile_maria]

Coming at this from a global operations perspective at Uber. We’ve been distributed-first for years, and I think the key is categorizing work types differently than most teams do.

The mistake I see is treating all work as either “sync” or “async.” That’s too binary. At Uber, we use a matrix:

Urgency × Complexity = Communication Mode

• High urgency + High complexity = Always sync (incidents, critical decisions)
• High urgency + Low complexity = Async with SLA (quick approvals, simple blockers - 2hr response time)
• Low urgency + High complexity = Hybrid (your RFC → debate → decision model, Keisha)
• Low urgency + Low complexity = Pure async (code reviews, status updates)

Here’s where this gets practical for my team across São Paulo, San Francisco, and Bangalore:

Code reviews: Always async. They’re complex but not urgent. No one should be blocked waiting for timezone overlap. We enforce 24hr review SLA - if no one reviewed your PR in 24hrs, you can merge it (assuming CI passes).

Incident response: Always sync. You can’t wait 8 hours for Bangalore to wake up when the payment system is down. We have paid on-call rotation with clear escalation paths.

Architecture decisions: Hybrid. Async RFC with 72hr comment period, then ONE 90-minute sync debate scheduled for maximum timezone overlap, then async approval process with 48hr deadline. Forces closure.

Performance reviews and 1-on-1s: Sync but timezone-flexible. This is where Maya’s rotation idea could work - manager adjusts to the engineer’s timezone sometimes.

The São Paulo to SF gap taught me this framework. It’s only 3-5 hour difference depending on daylight savings, which is “easy mode” compared to APAC. But even that gap breaks things if you’re not intentional.

One thing that doesn’t work: timezone rotation for regular team syncs. It sounds fair but everyone ends up miserable at different times, which is still miserable. Better to optimize for the majority timezone and compensate the minority (async summaries + recordings + occasional early/late meetings with comp time).

My rule of thumb: If you can’t clearly articulate why something needs to be sync, it should be async. Make sync the conscious choice, not the default.

[product_david]

Product perspective here, and I’m going to push back a bit on the async-first orthodoxy.

I watched async-first kill product velocity at my previous company. Here’s what happened:

Customer reports bug → PM investigates → async Slack to Engineering → Engineer responds 4 hours later asking for details → PM provides details next morning → Engineer says needs Design input → Design responds end of day → Engineering says actually this is deeper, needs architecture discussion → RFC created → comments accumulate over 5 days → finally we schedule a meeting to decide → decision made, work starts.

Total cycle time: 8 days for a customer-reported bug.

Meanwhile, our competitor (smaller, scrappier, less “process mature”) would just hop on a call when a customer reported something critical. They’d have a fix in production in 24 hours.

We were optimizing for distributed team harmony while they were optimizing for customer outcomes.

Here’s my contrarian take: Async-first can be premature optimization.

If you’re 10 people, just talk to each other. The overhead of maintaining documentation, waiting for async responses, and context-switching across threads might exceed the cost of having some meetings.

If you’re 100 people across 8 timezones, yes, you need async infrastructure. But even then - your actual constraint isn’t documentation, it’s decision-making authority. The teams that ship fast have clear DRIs (Directly Responsible Individuals) who can make calls without consensus.

Keisha, I’m curious: When you analyzed those 3 weeks of RFC paralysis, was the real problem async communication, or was it unclear decision-making authority? Could that engineer have just made the call and moved forward?

Sometimes we blame the medium (async vs sync) when the real issue is organizational design (who can decide what).

That said, I love your “Synchronous Moments That Matter” framework. I’d add one more category: When you need to move faster than async allows. Sometimes speed is the strategy, and that requires tighter loops than documentation can provide.