When Should You Have a Meeting? 🔋

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

Hey 👋 this is Luca! Welcome to a 🔒 weekly edition 🔒 of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

You can learn more about Refactoring here.

To receive all the full articles and support Refactoring, consider subscribing 👇

---

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 👇