🔍 Less Talk, More Code: Working asynchronously to reduce the meetings that could have been an email

Fragmented schedules filled with meetings often reduce productivity and focus. This article explores the benefits of shifting to asynchronous communication, allowing developers to tackle complex tasks

Let’s get honest here.

As software engineers, our days are usually fragmented with meetings, causing context-switching, and breaking our focus.

We want to have long stretches of no distractions to code and review code.

By shifting certain meetings to an asynchronous model, we can work on complex tasks without interruption.

A meeting is a mechanism, not the end goal. By understanding the purpose behind the meeting, we can find an async alternative to serve this same purpose.

In today’s articles, I’ll offer practical asynchronous alternatives for our typical meetings.

⭐ In this post, we’ll cover

1. What makes async the right tool, and what makes it fail

2. A practical scenario of how I applied this last week when meeting with the Senior and Principal Engineer from another team

3. 10 meetings that can be optimized with asynchronous work

4. Best practices and tools to collaborate asynchronously

⚖️ Async done right and async done wrong

Async only succeeds when it's properly managed and orchestrated.

Without someone to guide the process, async efforts often fall apart. When team members fire-and-forget updates, discussions become fragmented, leaving critical points unresolved.

However, by managing async communication and reserving live meetings for items that truly need collaborative input—like aligning on blocked work— teams can keep meetings smaller and more focused.

This way, async processes bring the best of both worlds: clear communication with fewer interruptions.

🤝 How I Applied This Last Week

I needed to consult with a Senior and a Principal Engineer from an external team to address some operational concerns about our integration.

Specifically, I wanted to validate alternative approaches I had for the integration and recommend updates to their provided code and documentation

I could have set up a basic agenda like:

Agenda

1. Discuss availability concerns for our service

2. Discuss observability concerns for our service

But this agenda was vague and offered little context. Instead, I prepared a document with detailed topics, each one containing a problem, a proposed solution, and a list of questions.

This allowed the Senior and Principal Engineers to review asynchronously, add answers, and address concerns before our meeting.

This is an example of one of the topics I had to discuss: