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 👇