How to Reduce Meetings πͺ
Strategies and practical ideas for better async communication, and a detailed case study.
I spend ~10% of my time doing some consulting to teams who want to work better together.
I do this to stay grounded to reality, and not to eventually turn into one of those ivory tower writers who talk about things they donβt really know anymore.
In these chats, the absolute #1 complaint I hear is: βwe do too many meetingsβ.
These thoughts are popular even outside the β admittedly small β sample I can observe. A few years ago, Pluralsight ran a wide survey where engineers ranked the biggest offenders to their productivity.
Meetings got the silver medal π₯ right behind waiting for other people to do stuff. But while waiting for people is a necessary evil sometimes, boy do bad meetings feel like a waste of time!
So, today I am sharing my best ideas + real-world, practical examples of meetings that have been successfully removed, and how.
Here is the agenda:
π ββοΈ Meetings culture β why meetings are so divisive today.
π₯ Meetings extremes β why extreme examples you find online are just wishful thinking.
βοΈ Status vs Action β the goals of a meeting and those of its attendees. You canβt cut anything until you donβt understand those.
πͺ Unbundling meetings β how to make a meeting smaller or remove it altogether, in practice.
π Case Study β we take a real-world, bi-weekly, 2 hours review + planning, and make it graduallyβ¦ disappear!
Letβs dive in!
π
ββοΈ Meetings culture
Meetings have become an extremely divisive topic in tech. But why is that?
I suspect because most of them are asymmetric by nature β that is, they benefit one subset of the participants, while being a waste of time for others. This is, for example, one of the main battlefields where engineers fight their evergreen war against managers:
π¨ Engineers β feel like they create the most value through deep work, so they despise meetings.
π½ Managers β often use meetings as the primary way to exert their influence and move the ball forward.
This feud is reflected, more broadly, in the different types of cultures we see today in tech. At the two ends of the spectrum, in fact, we see calm companies vs hustle companies:
π§ββοΈ Calm companies β are remote-friendly, async-first, and are good at minimizing meetings.
πββοΈ Hustle companies β are about intensity, everybody in the same room, and speed of results. They believe that calm companies are lazy and that meetings are crucial.
Likewise, many famous examples are also extreme: companies like Doist or GitLab do almost zero meetings, while, at Elonβs X, engineers are seemingly stuck in the office and summoned for design reviews at midnight.
Who is right?
I donβt feel anyone should be strictly in favor or against meetings. We just need to realize that meetings are the most powerful weapon we have in our communication arsenal. So, as a powerful weapon, we should be deliberate about when to use it.
Meetings, in fact, are high bandwidth and high effort:
1) π°οΈ High Bandwidth
In a meeting, you are able to exchange more information, and faster, than in any other way.
A good chunk of that 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 β which also speeds up decision making.
2) π High Effort
For the same reason, meetings drain everyoneβ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.
So, what should you do? π
π₯ Meetings extremes
Rather than looking at popular but extreme examples, most teams should rather focus on building a culture that keeps a few, good meetings, and aggressively cuts the rest.
When I work with companies on this, many have tried to do so by themselves, but fell victim to these extremisms:
βοΈ βWe should remove all useless meetingsβ β well, of course, but this is just wishful thinking. I have seen very few meetings that are actually useless. They may be inefficient, or too long, but never totally useless. The good news, though, is that you can remove/reduce useful meetings, too.
π βWe should replace meetings with docsβ β again, this is not wrong, but in most cases you canβt replace a full meeting with a doc. More realistically, you can use docs to make a meeting leaner and remove some parts, while keeping those that legitimately deserve sync discussion.
Extreme expectations can get you stuck, while you can make good progress instead by addressing problems individually, with baby steps.
So, it is often the case that you canβt remove a meeting altogether, but you can make it 20% its current size, and maybe remove 50% of the participants.
How can you do so? Letβs talk about why we have meetings in the first place, and why people join them π
βοΈ Status vs Action
Meetings are complex because of two problems:
There are various types β based on what we want to achieve with them.
People join for different reasons β based on their role in the process.
To make a meeting better, or remove it entirely, we need to figure out both.
Three kinds of meetings
I believe work meetings have three main goals:
π Sharing info β for status update. As you do in a sprint review, or when you demo new features to stakeholders.
π² Making decisions β for when you need to decide how to move forward. E.g. in a planning meeting when you prioritize stuff and decide what to work on next week.
𧱠Creating stuff β brainstormings, design sessions, problem solving, and anything where something gets created through the collaboration of the participants.
These goals live on an ideal line that goes from mostly passive/unidirectional communication, to mostly active/multidirectional.
More simply, it goes from status to action.
There is at least a fourth kind of meeting, that is about team bonding: celebrations, mob programming, watercoolers, and more. These are extremely valuable, but I pit them in a different category as they focus on relationships rather than actual output.
So, just like there are different kinds of meetings, there are different kinds of attendees:
RACI Chain
The RACI chain is a popular tool to identify the various roles of people in a process. It works well for meetings as well. RACI pits people into four categories:
π¨ Responsible β those who actually do the job.
π Accountable β those who ultimately sign off on the job and are answerable for it.
π€ Consulted β those whose opinions are sought but do not work directly on the job.
π£ Informed β those who are kept up-to-date on the status of the job.
If you think about them as meeting attendees, itβs easy to see that each role is interested in different things:
π£ Informed people are interested in status. They donβt make decisions nor participate in doing stuff.
π Accountable people make decisions and need status to do so. But they donβt join the creation process.
π¨ Responsible people donβt need info (they provide it to others). They usually join in the decision making, and also build stuff themselves.
π€ Consulted people donβt need info and donβt participate in the decision making, but may be involved in the building part as domain experts.
Ok Luca, enough with the theory β why is this useful in practice? Well, I have two strong beliefs that strictly descend from this:
πͺ Meetings should be unbundled β most meetings do not belong to a single type: they are a mix of many, because they need to suit different stakeholders. Rather than removing a meeting altogether, you can remove some parts (and some attendees), to make the rest shorter and more cohesive, so that nobody thinks they are wasting their time.
π You should use meetings for action β meetings have high bandwidth. The best use of such bandwidth is for creating things and solving problems, rather than sharing information. The latter can be usually done asynchronously just as well.
So, the best way to reduce meetings is to 1) split them into parts, and 2) remove / make async those about status.
Letβs see practical steps to do so, and wrap up with a full case study π