You face will look like this ⬆️ after endless meetings in the organisation. In this post, I’d like to talk about my approach to dealing with meetings.

TLDR

My strategy to deal with meetings:

1. Cut meetings that lead nowhere.
2. Send agenda, prepare materails beforhand.
3. Keep it short and with fewer people as possible, 40 min max.
4. Make actionable decisions with the person responsible for the task.
5. Take notes and send follow-ups.

Intro

If you were ever in a managing position at a big software company, especially doing architecture, or you are in a consultancy business, then meetings will be the big part of your work.

Your schedule is almost always planned from 9:30 to 16:00 with meetings, meetings and meetings. Meeting hell!

When I first started to do architecture, I was excited about meeting all the teams in the company: India, France, USA. Sometimes more than hundred people in a call. After a few months I started to hate meetings. Because they steal time and make big part of the day unproductive. Most of the time there is no agenda, just status update or QA session. There is usually no action items or clearly defined outcomes.

After few years I learned that having 30 minutes per week per person for status update and 30 minutes per week for a team for planning tasks together is enough.

Strategy

Here is my recipe for productive meetings:

1. Is it needed? The first and most important question to ask is if the meeting is needed at all. When I was junior software engineer in multinanational companies I was often invited to meetings where I did not have either expertise or knowledge to give an advice.

   Imagine sitting in the meeting and saying “hello”, “yes” and “goodbye”. While other people discuss unrelated to your job task for an hour. At the end of this hour, you do not have any new information, but it took your time and deprived you of an opportunity to complete your coding tasks.

   Less people are in the meeting, shorter it is, better it is. Use face-to-face communication instead of conference calls. Good email or wiki post is an efficient way to start an asynchronious discussion without needing to schedule time for many people.

2. Structure - keep the goal in sight. Before the meeting, make sure to create an agenda and send it to everyone who will attend. Include a title, the topics that need discussion, decisions that must be made, and any questions that should be considered. I usually make a presentation which covers the agenda and use it to take notes.

3. Keep it short - I’ve already mentioned this in the introduction, but it’s worth stressing again. The shorter the gathering, the better it is. Forty minutes is the maximum attention span you can hope for from any group; after that, their minds will start to wander and some will even pull out their phones to start browsing Reddit. Aim for twenty to thirty-minute meetings that are jam-packed with exchanging knowledge and ideas. Less is more.

4. Take notes and create action points. What do I mean by this? I’m talking about identifiable tasks with the person responsible assigned, and a timeline for completion. As I was part of the architecture group for the software, our meetings lasted several hours each month and all we could agree on was when we should meet next. Meetings should have results: tasks to be implemented, and a means to validate them. For instance, a positive outcome for the meeting task could look like this: “Jerome will develop an architecture for communication between multiple processors using SPI and DMA per the protocol documentation by the end of the following week, so that we can proceed with validating it against the requirements XXX…”

5. Right after the meeting, send a follow-up email with notes, observations, items to act on, and decisions made to every participant. Everything that is not written will be forgotten.

Conclusion

I strongly suggest using asynchronous communication in written form instead of attending meetings. Text-based conversations such as emails should replace the need for them.

Do not use a platform like Slack or chat messengers to make technical decisions as it can be hard to recall what was said in a wave of messages. Structured posts (like Basecamp), documents(Slides), and notes (like OneNote) provide much clearer communication platfroms.

I’m hoping this post will help to prevent you from having a terrible meeting experiences for the team in your work.