Why I prefer async work over meetings

I prefer a written update to a recurring meeting when the purpose is simply to share progress. I can read it when I reach a stopping point, ask a specific question, and find it again later.

That preference has limits. A thread can waste an afternoon just as easily as a meeting can. Async work needs clear requests, response expectations, and someone responsible for the decision.

Give an update a job

A useful update tells the reader what changed and whether they need to act.

A list of everything I did yesterday is often less helpful than a short note saying that the import flow is ready for review, one error case remains unresolved, and I need a decision about the file-size limit.

If I need a response, I name the person and say when it's needed. Otherwise, people have to guess whether the message is background information or a blocker.

I also link the work itself. A screenshot can help, but the person reviewing an interaction usually needs a preview they can use.

Write the decision, including the disagreement

For a technical decision, I want the problem, the constraints, the options seriously considered, and the proposed choice. The length depends on the consequences. A small reversible change doesn't need an essay.

The document should also say who decides and what happens next. Without that, comments can accumulate without producing a decision.

When the team chooses an option, record why and keep the rejected alternatives short. That gives a future colleague a chance to understand the trade-off instead of assuming nobody considered it.

If the decision happens on a call, it still needs that written record.

Agree on response times

Async doesn't mean everyone must watch chat all day. It also doesn't mean a blocking question can sit unanswered indefinitely.

A team needs a rough agreement about which channels are checked, how quickly routine requests should be answered, and how to signal urgency. The exact arrangement depends on working hours and time zones.

I find a stated deadline easier to work with than repeated “any update?” messages. “I need this by tomorrow afternoon to finish the release” lets someone plan or tell me they can't do it.

Emergencies need an agreed route that actually reaches someone. Posting an outage in a quiet project channel is unlikely to be enough.

Know when to talk

I switch to a conversation when we keep interpreting each other differently, when the issue is sensitive, or when a short live session would resolve several dependent questions.

Live collaboration can also be useful for exploring a problem together. It doesn't have to be reserved for emergencies. Some people think more clearly through conversation, and a written-only culture can exclude them.

The point is to choose the format deliberately. A call with a clear purpose, the right people, and a recorded decision can save time.

Try changing one meeting

I'd start with a recurring meeting whose purpose is mostly status sharing. Replace it for a short trial with a written update in one predictable place.

Then check what happened. Were blockers noticed? Did decisions take longer? Did people spend the saved meeting time chasing replies in chat?

If the change helps, keep it. If it doesn't, adjust the format or restore the meeting. I care about having enough uninterrupted time to do the work and enough contact to stay coordinated. The calendar is only one part of that.