Async-First: How to Run Your Team Without Real-Time Meetings

The Experiment We Ran

In our async communication guide from February, we told you to try going more async. But advice is cheap — so we decided to eat our own cooking. In May, our product engineering team (14 people across 3 time zones) committed to a 90-day async-first experiment.

The rules were simple: no meetings by default. Every interaction should start as async (document, Loom, Slack thread). A synchronous meeting could only be scheduled if the async attempt failed or if the topic genuinely required real-time discussion. We tracked everything — meeting count, focus time, cycle time, satisfaction, and communication quality.

Here's what happened.

The Results: What Improved

Focus time skyrocketed. Average daily focus time (uninterrupted blocks of 2+ hours) went from 2.4 hours to 3.7 hours — a 54% increase. Our own Teambridg dashboards confirmed this wasn't just perception; it was measurable and consistent across all team members.

Output velocity increased. Sprint velocity (measured in story points) improved by 18% over the 90-day period. This wasn't because people were working more hours — average work hours actually decreased slightly. They were working more effectively because they had longer blocks of uninterrupted time for deep work.

Satisfaction improved. In our end-of-experiment survey, 11 of 14 team members said they preferred the async-first model. Common themes: less context switching, more control over their schedule, less meeting anxiety, and better documentation.

Time zone equity improved dramatically. Our colleagues in Europe and Asia-Pacific reported feeling like first-class team members for the first time. When everything is documented rather than decided in a meeting they couldn't attend, they have equal access to information and equal voice in decisions.

The Results: What Got Harder

It wasn't all rosy. Here's what got harder during the experiment:

Documentation burden: Async-first requires significantly more writing. Decisions, context, design rationales — everything needs to be written down. In the first month, people found this exhausting and time-consuming. By month three, it had become natural, but the initial investment was real.

Speed for urgent issues: When something broke in production at 3 AM, async wasn't the answer. We learned to maintain a clear escalation path: async by default, Slack DM for urgent, phone call for emergency. The key was defining "urgent" clearly so it wasn't used as an excuse to bypass async.

Relationship building: Casual social interaction decreased. Without meetings, there were fewer moments for banter, personal check-ins, and the informal bonding that builds trust. We compensated by scheduling (yes, irony noted) optional weekly social calls and by being more intentional about personal messages in Slack.

The Meetings That Survived

Not all meetings were eliminated. The ones that survived the async filter — and were unanimously valued — were:

Weekly team retro: Retrospectives benefit from real-time emotional processing and group problem-solving. Our remote retro guide applies here with async pre-work and sync discussion. Complex design discussions: When exploring genuinely novel problem spaces, the rapid iteration of live discussion outperformed async back-and-forth. These were typically 50-minute sessions with 3-5 people. 1:1s: Bi-weekly manager-report 1:1s remained synchronous. The relationship and nuance of these conversations didn't translate well to async.

Everything else — standups, status updates, planning sessions, most code reviews, all-hands information sharing — went async and stayed async. The team's quality of life improved measurably, and output improved measurably. We've made async-first permanent for the product engineering team and are rolling it out to other departments.