Asynchronous vs. real-time collaboration: finding the right balance for your team

Count the meetings on your team’s calendar this week. Now estimate how many of them produced a decision that couldn’t have been made in a well-written document or a short Slack thread.

For most teams I’ve worked with, the answer is uncomfortable. Engineers are losing multiple hours a day to synchronous coordination that doesn’t actually need to be synchronous. At the same time, going full async isn’t the answer either. I’ve seen teams drift into complete disconnection trying to do everything in writing, with decisions dragging out for days and engineers who barely know each other.

The question isn’t “async or real-time?” It’s “which one, and when?”

What async is actually good for

Async collaboration gets mislabeled as a remote-work thing. It’s not. It’s a focus thing. Any team, in the same office or across twelve time zones, benefits from reducing the number of moments where work requires simultaneous presence.

PR reviews are the obvious one. An engineer doesn’t need to be on a call to review code. They can look at it when their own block of focused work is done, leave thoughtful comments, and the author can respond on their own time. The review is often better for it: people read code more carefully when they’re not performing on a video call.

Technical proposals and RFCs are another good fit. If a senior engineer writes up a system design and shares it for comment, the team gets 48 hours to read it carefully, think about edge cases, and respond with actual depth. The alternative, scheduling a meeting to present the design, typically means most people haven’t had time to think before the discussion starts.

Status updates almost never need to be meetings. A short written update in Slack or your project tracker takes five minutes to write and two minutes to read. The daily standup that accomplishes the same thing takes thirty minutes and interrupts everyone’s morning.

Good async depends on good documentation. None of this works if information lives only in people’s heads or in meeting notes nobody reads. Teams that do async well invest in written communication as a skill: clear proposals, detailed PR descriptions, meeting summaries with actual decisions recorded.

What genuinely needs to be real-time

There are categories of work where async actively makes things worse.

System design whiteboarding sessions are one. When a team is trying to think through a complex architecture, the live exchange of questions, pushback, and real-time diagram sketching produces something that an RFC comment thread takes three days to approximate. Some thinking benefits from real-time collision.

Retrospectives need to happen live. The value of a retro isn’t in the list of what went well and what didn’t. It’s in the conversation that happens when someone says something that five other people have been thinking but haven’t said. That conversation doesn’t happen in a written doc.

One-on-ones should never go async. A one-on-one is not a status update. It’s a space for an engineer to say something they wouldn’t put in writing: that they’re frustrated, that they’re thinking about leaving, that they feel stuck. Async check-ins feel efficient and miss everything that matters.

Incidents require immediate coordination. When something is down, you need voices in a call, not a Slack thread where messages come in at different speeds from people with varying levels of urgency about the situation.

And then there’s team culture. Relationships don’t form in Slack. People need to actually talk, even if that talk is just a casual Friday coffee chat with no agenda. Fully async teams can function, but they often feel hollow: colleagues rather than a team.

How to calibrate this in practice

The test I use for whether something needs to be a meeting: can this be resolved with one or two back-and-forth messages? If yes, don’t schedule a meeting. If the answer involves more than two people needing to converge simultaneously on a nuanced decision, schedule the meeting and document the outcome.

Protect focus time explicitly. If engineers have two-hour blocks of meeting-free time that are visible on shared calendars, other people stop scheduling into them. This requires managers to model it first: if leadership books meetings freely, the team won’t feel entitled to protect their time.

Set async response expectations clearly. “Async” without norms becomes “I sent a message and heard nothing for three days.” Most teams do fine with a 4-hour response window during working hours for non-urgent questions. The key is agreeing on it explicitly, not assuming everyone operates the same way.

The balance isn’t static. A team in the middle of a major release needs more real-time coordination than a team in a steady feature-delivery cycle. Pay attention to how the team feels: if people seem disconnected, add touchpoints. If they seem overwhelmed and scattered, remove them. It’s a dial, not a switch.