Async by Default

My team is 90% remote. It took us a few years to figure out when to meet and when to write.

Industry-wide studies say that developers spend only a small fraction of their time writing code. The rest goes into reviewing code, writing documentation, communicating on different channels, and meetings.

All these activities fall into two buckets: working alone and working together.

Both are important.

Individual work is when the code and consequently value is produced.

Working together with others supports individual work and does not usually produce value directly.

However, collaboration is unavoidable in organizations larger than one person.

The real question: “How to find the right balance between collaborating with others and individual work?”

The Challenge

Striking the balance is often a challenge. On one side of the spectrum are technical organizations drowning in meetings. Developers don’t have time to code, and essential technical work moves at a snail’s pace.

The other side of the spectrum is very anti-meeting. This creates its own problems. Developers become disconnected from the business and from each other. Misalignment grows, technical debt accumulates faster than anyone expects, team cohesion and spirit take a hit.

Async as the Default

My preferred way for balancing collaboration and individual work is by moving some of the collaboration to asynchronous mode. For example, instead of having a status update meeting, everyone writes an update to the team’s Slack channel.

Another example is turning a face-to-face architecture design meeting into an asynchronous RFC review. (You can read more about using internal RFCs here: https://highimpactengineering.substack.com/p/the-illusion-of-shared-understanding)

A Spectrum: From Easy to Hard to Do Async

Let’s go from the least difficult activities to do asynchronously to the most difficult.

1. Informing

All kinds of reports and status updates can be done asynchronously using Slack, email, or written memos. An additional benefit is that unlike face-to-face updates, written updates can be easily shared.

2. Problem Solving

Many technical problems are better handled async.

When someone needs input, feedback, or review, they can share a proposal or prototype with the team. People contribute their thoughts on their own time.

This reduces interruptions and leads to more thoughtful contributions.

3. Decision-making

Decisions don’t always require a meeting.

If the facts are clear and consensus isn’t critical, async decision-making works well.

But when ambiguity is high—or you need explicit group buy-in—a synchronous conversation is worth the time.

This is one of the key judgment calls for engineering leads.

4. Innovating

Innovating can be done asynchronously but in my experience the best ideas are born in real-time interactions such as workshops and hackathons.

When the goal is creativity, synchronous time has a magic that async cannot fully replace.

5. Building Personal Connections

Building personal connections does not work well through chats and email, but thrives when people meet in the same place. This is why offsites, in-person gatherings, and even regular face-to-face calls help teams build trust and ultimately work better together.

A two-day offsite can build more trust than months of Slack messages.

How We Apply This

Depending on where you are on the meeting-heavy to anti-meeting spectrum, different changes might be needed. In my practice I have been on both sides. After iterating for a while I found a few strategies that work well.

Split planning into two parts

One of the biggest wins has been splitting planning into two parts. Feature or large increment kick-offs are held face-to-face.

Detailed technical planning is done primarily asynchronously using RFCs.

This split gives the team shared understanding of the bigger picture without going into details that would be premature. We innovate, decide, and connect during the kickoff—and then individuals do the deeper planning work on their own.

Dailies: keep or skip

As mentioned earlier, status updates are the easiest to do asynchronously. However, for remote teams a camera-on daily meeting might be essential.

For a developer the daily meeting may be the only touch point with the rest of the team. It helps team members stay connected to each other.

In this case daily serves a double purpose: both informing and connecting.

For teams that work primarily on-site, I believe the daily can be moved to async—people only meet to address blockers.

Async UI design reviews

Another thing we do primarily asynchronously is UI design reviews. We use screen recordings, sometimes with voice-over. Review requests have deadlines and assign reviewers.

This not only saves time but produces better results—people have time to digest the proposal.

Finding Your Balance

Implementing these strategies helped my team move faster while staying connected to each other and to the business.

If you like the idea, look at your collaboration patterns.

Ask:

Does this activity really need to be synchronous?

Does the team feel sufficiently connected to each other?

Would more face time help? With each other? With stakeholders?

Where is async clarity missing?

Where is synchronous energy missing?

Getting this balance right can dramatically improve a team’s velocity, alignment, and well-being.

Thank you for reading.

This is the second essay in the series on communication in technical teams. If you’d like to receive new essays weekly, subscribe to High-Impact Engineering.

Originally published at High-Impact Engineering.