When Should You Have a Meeting? πŸ”‹

And a small framework to decide what requires a meeting and what not.

A couple of weeks ago we discussed how communication should be designed inside our team. This is of course a very broad topic, and I started from a specific angle that is about responsibilities.

I also wrote briefly about the "Async vs Sync" feud. A few people reached out for advice and in the last few days I had some great conversations about meetings, calls, shared docs, and all kinds of ways of sharing information with your team.

When you get down to it, the big question is: how do you decide when something is worthy of a meeting, or is it better to be handled offline β€” with some written exchange or another way?

Let's work this out and build a simple framework, starting from first principles πŸ‘‡

πŸ”€ Async Communication

When we speak of "Async Communication", we usually mean a bundle of two qualities:

  • Async Communication – working with people in separate moments of time, not all together.

  • Written Communication – writing things down instead of saying them out loud.

I know, this is a bit trivial, but it was worth pointing out because these qualities do not always happen together.

You have work that is written, but real-time (e.g. shared docs in meetings, pair programming), and also communication that is async, but not written (e.g. audio messages).

These things aren't bad β€” writing a doc together in a meeting is often great β€” but they don’t provide as much as a shift as coupling writing and async together.

Let's discuss why both are great, and how this is different from meetings πŸ‘‡

Written over Verbal

With respect to verbal communication, written text has a few advantages:

  • πŸ—οΈ Durable β€” things stay there for the record, instead of living only in people's memories.

  • πŸ” Searchable β€” it can be indexed and searched efficiently, as opposed to live speech or audio messages.

  • πŸ’­ Thoughtful β€” it requires more work to be created, which leads to a better quality output.

Async over Sync

Written communication upsides nicely combine with those of Async communication. In fact, Async is:

  • πŸ’­ Thoughtful β€” by having more time to react, as opposed to real-time, people can provide a better output that is also less subject to groupthink.

  • ⏱️ Efficient use of time β€” needing to speak with everyone at the same time creates only so many opportunities to do so. Working asynchronously reduces bottlenecks by allowing people to contribute in more ways, on a more flexible schedule.

  • πŸ”‹ Low Energy β€” async work can be sustained with good productivity for more time than meetings or calls.

πŸ”„ Meetings

After reading the previous paragraphs you might be thinking: is Luca saying we should move away from meetings altogether? The answer is a big no!

In fact, meetings are actually the most powerful weapon you have in your communication arsenal. It's just that, as a powerful weapon, you should be very deliberate about when to use it.

This is because meetings are high bandwidth and high effort πŸ‘‡

High Bandwidth

In a meeting, you are able to exchange more information, and faster, than in any other way.

A good chunk of this information is non-verbal, like body language and tone of voice. This allows to build connection and get emotional feedback in a way that is just not possible otherwise β€” and that also speeds up decision making.

Unfortunately, a good chunk of non-verbal information gets lost in calls, which seems to be the reason why calls are more exhausting than meetings, and way less valuable.

High Effort

For the same reason, meetings drain people's energy pretty fast. Both the meeting's fatigue and the expectation of the fatigue itself can derail people's productivity in a way that vastly exceeds the time actually spent in the meeting.

As Paul Graham said in the famous Maker's Schedule, Manager's Schedule:

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there's sometimes a cascading effect. If I know the afternoon is going to be broken up, I'm slightly less likely to start something ambitious in the morning.

So when should we use meetings? πŸ‘‡

β˜• The C.U.P. rule for good meetings

Meetings are incredible tools, we should just use them sparingly.

A good rule of thumb for when to use a meeting is to follow the CUP rule. Use meetings for:

  • Complex matters β€” e.g. a design session where several people need to converge on a solution.

  • Urgent matters β€” anything where you need to act really quick, like incidents.

  • Personal matters β€” anything where emotional connection matters, like 1:1s or team building moments.

Basically, these cases mirror the major pitfalls of async communication:

  • Slower β€” by definition people have more time to react, thus increasing the time needed to take a decision.

  • Unemotional β€” this is not a downside by itself, as many conversations benefit from not being emotionally charged. But in some cases you need connection, and chats & docs are not going to cut it.

90% of communication in a company is neither complex, nor urgent, nor personal. Still, meetings are often the default way of addressing anything that should be done.

Why? And how can we reverse the trend? πŸ‘‡

✍️ Build a written default

Meetings, though expensive, are very easy to summon. You don't need any particular process: you create an event on the calendar and invite the relevant people. That's why they become the easy default.

Any async/written counterpart, instead, needs work to be set up. If you want to make async the new default, you should design it to be as effortless and reliable as meetings.

How do you understand if what you have in place today is good enough? Ask yourself a few questions:

  • Documentation β€” if you want to create a doc about some specs/information, how easy is it to do? Do you know where to put it? How confident you are that it will be found by other people and used in the future?

  • Decisions β€” if you need to converge with others on something, do you have a reliable place to do it in written form? Do you trust this place not to get lost and to be referenced in the future?

Good answers to these questions are the result of hard, deliberate work that builds up over time. So even if you feel you are not there yet, don't get discouraged and keep working on it!

You can get some help from tools πŸ‘‡

πŸ”¨ Tools for Async Communication

A few great tools that promote an Async workflow, vs their more popular counterparts.

  • Twist over Slack β€” Twist encourages structured, long-lasting exchanges instead of ephemeral chat. It has a sane management of notifications and is less messy overall.

  • Notion over Google Docs – one reason why often we don't stick to writing docs is we don't feel we are building something durable. Notion fixes this by encouraging a hierarchical structure of notes, and by allowing to connect pages in multiple ways (to say the least).

  • StatusHero or Range over regular stand-ups/check-ins β€” async check-ins are rising in popularity, and these tools are the best ones I know to support them. They connect with Slack, Email, and production tools like Trello, Clubhouse and GitHub to give you rich context into what other people are doing, without needing to jump in a call.

πŸ“š Resources

  • πŸ“‘ The Reason Zoom Calls Drain Your Energy β€” by Manyu Jiang. Very insightful article about the physiological differences between meetings and calls. It turns out calls are more exhausting because it's harder to get non-verbal cues than in regular meetings.

  • πŸ“‘ The 7 Types of Meetings That Should Always Be Async β€” by Aer Parris. I know, I have already shared this two weeks ago! The reason why it's here again is 1) it's a great article, 2) it's very on point with this week's topic, and inspired many of the considerations I made here.

And that's it for this week! Have you been able to replace some meetings with other kinds of interactions? Do you have any tips? Let me know in the comments πŸ‘‡ or via email


Hey, I am Luca πŸ‘‹ thank you for reading this far!

Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.

Subscribe below to receive a new essay every Friday and put your own growth on autopilot!