When to Use Async vs Sync Engineering Communication (and When You'll Regret Picking Wrong)
TL;DR: Default to async. Switch to sync the second a thread bounces more than twice without convergence, anyone seems frustrated, or the decision can't be reversed. The trick isn't picking one or the other. It's knowing when to flip.
My team at a previous job had a "design sync" on the calendar. Every Tuesday, 90 minutes, 8 engineers. We kept it because we'd always had it.
I killed it one quarter. Replaced it with a Slack thread.
Three months later we brought it back. Different format, half the time, half the people. The hybrid version worked. The pure-async version had a quiet failure mode I didn't see coming, and most of the async-first advice on the internet skips this part.
This is fine. The recurring 90-minute meeting is fine. (Giphy search: this-is-fine-dog)
When should engineers default to async?
For the boring 80% of work communication, async wins. Status updates. PR feedback. Roadmap context. Anything that doesn't need a decision in the next hour.
The reasons aren't subtle:
- Writing forces clarity. You can't hand-wave on a Loom or in a doc.
- It documents itself. Six months from now, the Slack thread is searchable. The Zoom call isn't.
- It respects deep work. A 4-hour focused block beats six 25-minute slices.
- It scales across time zones without burning anyone's evening.
The GitLab handbook on async work is the canonical reference here. If you haven't read it, read it. It's the most thorough public document on async culture anywhere.
When does sync actually beat async?
Five situations. Specific because the generic version of this list ("complex discussions, sensitive topics, etc.") doesn't tell you anything useful.
1. The conversation has more than 4 unresolved replies in a thread.
If you and a teammate have gone back and forth four times and you're still not aligned, you're in a debate loop. Each new reply adds context but doesn't move you toward convergence. The fifth reply is almost always going to be the sixth reply.
Hop on a call. Five minutes synchronous saves you 90 minutes of typing.
2. Anyone's frustrated.
Slack is a terrible medium for frustration. The other person can't see your face, can't hear your tone, and is reading your words while their own emotions interpret yours. A short voice call deflates 80% of Slack tension in about 90 seconds.
The hard part: you have to be the one to suggest the call. Default response is "let me jump on a quick call so we don't have to keep typing, I think we're saying the same thing."
3. The decision can't be reversed.
Architectural choices, hiring decisions, comp, public commitments to customers. Once it ships, it's a multi-month rollback. These deserve real-time discussion because the cost of misalignment is huge and the cost of a 30-minute meeting is small.
The reverse is also true: a reversible decision (color of the button, name of the API endpoint, choice of test framework) should never get a meeting. Async it, ship it, change it later if needed.
4. Someone's new to the team.
For the first 60 days, default to more sync, not less. New hires don't have the implicit context to interpret a terse Slack message. "LGTM with nits" reads differently to a 4-year veteran and to someone in week 2. Onboarding burns sync time on purpose.
5. The conversation needs creative collaboration, not coordination.
Whiteboarding a system design, untangling a tricky bug, brainstorming a name. Async chokes here because the rhythm of half-formed thoughts is what makes the conversation work. You need the "wait, what if we..." moments.
What goes wrong when you over-async?
Everyone writes about the failure modes of meeting culture. Almost nobody writes about the failure modes of async-only culture.
Decisions don't ship. When the only way to make a decision is to convince everyone in writing, the decision sits in a "discussing" state for weeks. Nobody wants to be the one to call it.
Loud writers win. Async overweights people who write a lot, fast. The engineer with the strongest argument loses to the engineer with the most words. Sync at least equalizes airtime if the meeting is run well.
Junior engineers go invisible. A junior on a remote-async team often has no idea what's actually being decided. The senior engineers are DMing each other. The decision shows up as a fait accompli in a thread the junior couldn't have known to follow.
Threads die from politeness. "Let me think about that and get back to you" is the async version of "no decision today, see you next Tuesday." Without a meeting, there's no deadline. The thread just trails off.
The Tuesday design sync I killed? Three of those four failure modes showed up within six weeks. The good news: I knew what we'd lost. So I brought back a 45-minute version, async-first, with a hard rule that anyone could veto its existence at the end of any quarter.
That's the move. Not "async-only" or "default-sync." It's async-first with a deliberate, defended sync layer.
How do you write async messages that don't need a meeting?
The single biggest unlock for async culture: stop writing "thoughts?" and start writing decisions.
Drake rejecting "Thoughts?" / Drake approving "Decision needed by Friday EOD, default is yes." (Giphy search: drake-meme)
Compare:
Hey team — I'm thinking we should move the auth service to its own deployment. Thoughts?
versus:
Decision needed by Friday EOD: move auth service to its own deployment. Context: we've had 3 deploy conflicts this month tied to coupling. Trade-offs: +1 service to operate, −1 source of deploy contention. Default: yes, we move it. Speak up if you disagree by Friday and I'll switch to a sync call.
The second version does four things the first doesn't:
- Names the decision explicitly.
- Gives a deadline.
- States the default (silence = ship).
- Names the escalation path (disagreement triggers a call).
Adopt this format and async will start carrying the load it's supposed to carry.
This is the same logic as the 3-sentence disagreement playbook. Make the position legible, make the path forward obvious, lower the cost of objection.
What's the "two strikes" rule?
Try it async. If you bounce twice (two rounds of misunderstanding, two days without convergence, two angry-looking emoji reactions), you've earned the right to call a 15-minute sync.
The rule keeps you honest in both directions. You don't default to a meeting on round one. You also don't grind out 14 rounds of Slack hoping clarity will emerge.
I put "two strikes" in the team norms doc. It became one of those phrases people throw around in standup: "I think we're at two strikes on this one, want to hop on?"
How do you handle async with timezone overlap?
This is where most async-only advice falls apart. Real teams aren't fully distributed across 24 hours. They cluster in 2 or 3 time bands with maybe 4 hours of overlap.
The pattern that actually works:
- Overlap hours = sync time, on purpose. Don't burn overlap on solo work. Save standups, design reviews, and pairing for overlap.
- Outside overlap = async, by default. Asia engineer doesn't need to wait until US morning to ship.
- One handoff doc per shift change. "Here's where I am, here's what I tried, here's what's next." 5 minutes to write. Saves hours.
- Track decisions in a shared doc, not just Slack. Slack threads bury after 24 hours. A "Decisions" doc with date-stamped entries is searchable a year from now.
Charity Majors' writing at charity.wtf has some of the best examples of high-trust distributed engineering culture. Worth bookmarking.
Is async harder for junior engineers?
Yes. And teams that don't account for this end up with juniors who plateau in year one.
Async makes the implicit context invisible. Senior engineers operate on a huge amount of unwritten context (which deploys are dangerous, who actually owns what, what's been tried before). Async-first teams document none of it because the seniors already know it.
The fix isn't more meetings. It's:
- Weekly 1-on-1 with a senior engineer as a learning partner (separate from the manager).
- A "stupid questions" channel where nobody piles on.
- Junior engineers paired on PRs for the first 90 days, even if it slows velocity.
- Loom recordings of senior engineers thinking out loud during debugging.
If your async culture is brutal on juniors, it's not "high-performance." It's just a low-empathy team that hasn't paid for the gap yet.
How do I shift my team to async-first without a revolt?
You can't unilaterally cancel meetings. The team has to feel safer, not more abandoned.
The sequence that's worked for me:
Step 1. Pick the one meeting that has the highest ratio of attendees to actual decisions. Usually it's a recurring "sync" with vague goals. Propose a 2-week experiment: kill the meeting, replace with an async doc that anyone can comment on.
Step 2. Run a Slack rule: "If you write 'thoughts?' or 'let me know what you think,' rephrase as a default decision with a deadline." Make it a team norm, not a personal preference.
Step 3. Add a "two strikes" rule to your team doc. Codify it.
Step 4. After 4 weeks, look at the meeting calendar honestly. Anything still on it should be the meetings that actually need humans in real-time. Defend those. Hard.
Step 5. Re-evaluate quarterly. Some meetings come back. That's fine. The goal isn't zero meetings. It's that every meeting on the calendar earned its slot this quarter.
LeadDev has a strong archive of articles on engineering team operations if you want more material on this.
Where to next?
If your team's communication is broken in a more specific way, the rest of the Developer EQ blog covers the adjacent problems:
- The Loudest Voice in Standup Isn't the Most Effective — fixing the daily sync everyone secretly hates
- Stop Apologizing for Disagreement — the 3-sentence note that ends most async loops
- Code Review Is a Social Skill — async's hardest medium
- Why Your 1-on-1s Feel Like Dentist Appointments — the one sync you should never make async
- 12 Engineering 1:1 Questions That Actually Get Real Answers — the questions to bring once your 1:1 is unbroken
- The Engineer's Guide to Getting Promoted (2026 Edition) — the meta-strategy that connects all of this
Or, if you want the structured 14-day version with a guided team-comms exercise, the free Developer EQ Sprint workbook is the next step.
FAQ
Should engineering teams default to async or sync communication?
Default to async for everything that doesn't need a decision in the next hour. Switch to sync the moment a thread bounces more than twice without convergence, anyone seems frustrated, or the decision is irreversible. Don't go async-only; over-async teams quietly lose decision velocity.
What's the "two strikes" rule for async vs sync?
If a Slack thread or doc thread fails to converge after two rounds, call a 15-minute sync. Two strikes keeps you from defaulting to meetings on round one and from grinding out 14 rounds of typing hoping clarity will emerge.
Why do remote engineering teams over-rely on async?
Async feels more respectful (no calendar invites) and produces searchable artifacts. The hidden cost: decisions stall, junior engineers lose context, and loud writers win disproportionately. Healthy remote teams are async-first with a deliberate, defended sync layer for decisions and onboarding.
How do I write async messages that actually get responses?
Name the decision explicitly, give a deadline, state your default position, and name the escalation path. "Decision needed by Friday: X. Default is yes; speak up if you disagree." beats "Thoughts?" every time.
Is sync communication more inclusive than async?
Depends on the team. Sync is more inclusive for new hires and people who don't write fluently in English. Async is more inclusive for introverts, neurodivergent engineers, and people in non-overlapping time zones. Healthy teams provide both lanes, not one.
How long should a sync meeting last for engineers?
Default to 25 or 50 minutes (not 30 or 60). The 5-minute buffer between meetings is the single highest-leverage change you can make to a team calendar. If 25 isn't enough, you didn't prep enough.
This is part of the Engineering Communication series. Get the free 14-day workbook, 15 minutes a day, real exercises, no spam.