A lot of companies seem to think All Hands meetings are the most important meetings a company can have, make them mandatory, and schedule them right at the start of the week and/or day. Unfortunately, these meetings tend to span multiple departments for the purpose of what amounts to status updates only. Even worse is when stakeholders use this time to ask questions in front of the entire organization, thereby wasting everyone’s time who is not part of those specific departments. These high-level discussions can be of value but are best addressed asynchronously without holding everyone hostage. In truth, these meetings are announcements disguised as meetings.

The solution is not to use meetings as mechanism for sharing this information but instead post the information in the form of announcements. Using group chat, wiki, email, or whatever might be your primary source for sharing company-wide news, is a more effective means of communication for regular news and updates.

A common misuse of meetings is to schedule a meeting for planning and/or brainstorming purposes in order to gather ideas and, if lucky, generate next actions. These types of meetings result in people generating fewer good ideas rather than more. Worse, you can end up in the low energy Abilene paradox of poorly made decisions entirely.

Instead, have everyone spend time researching, thinking, and documenting ideas in detail without a meeting at all. People can then collaborate asynchronously while building upon shared ideas. If conflicts arise then, yes, schedule a meeting to resolve them. Otherwise, you can avoid the meeting to begin with.

Here’s Adam Grant on the subject:

Much like company-wide announcements, status updates (a.k.a. standups) are another kind of meeting disguised as an informational update. These meetings usually appear as department/team standups where everyone provides updates as to what they’ve been working on, what they plan to work on, and any blockers. Because none of this is written down, anyone that is sick or on vacation totally loses out on information shared in these meetings that might be of benefit to them.

Needless to say, this is another kind of meeting that is best served by sharing via group chat or whatever your primary form of asynchronous communication is. If it’s worth sharing, it’s worth documenting, and if it’s documented, do you need a meeting?

Next to Status Updates, these are the most loathsome of meetings. They are usually assembled in haste, have too many people, have no agenda and clear objective, or started out with promise but quickly devolved into Parkinson’s Law of Triviality — also known as bikeshedding — which states:

Even worse — and because the discussion has been reduced to common territory — the discussion is now within everyone’s circle of compentence for which all have opinions. Opinions are only useful as long as you have done the work to back them up but these kinds meetings are anything but that.

The solution to avoiding these meetings is to ensure you have a specific problem that needs solving with a strong focus on accomplishing that objective. Anything else is noise and a waste of everyone’s time.

Meeting people for the first time, welcoming new team members, etc. is best done in person via a meeting since you want to help establish connections between people by putting a face to a name. It’s much easier to get to know someone when you can picture them in your mind and have a general sense of their character.

One on ones are meetings where you meet with your boss (or fellow colleague) to discus career goals, team collaboration, support issues, feedback, and anything else that might be on your mind. These types of meetings are critical to have because they help build trust by reading body language and tone of voice. Additionally, these meetings can be sensitive in nature so creating a safe space for discussion will be more effective than text.

Every now and then, asynchronous discussions can get heated, misconstrued, or even too long to easily follow. This is when an impromptu meeting is necessary to not let tensions or debates draw out longer than necessary. Much like one on ones, being able to fully take in body language, tone of voice, emotions, and/or sensitive information, vital during disagreements when tempers are high, is easier to do in person.

Due to the sometimes sensitive content of these meetings, conducting a retrospective is a good way to resolve conflicts and also have a chance to celebrate the work of others, thereby building strong team bonds.

Successful retrospectives come with a caveat which is to ensure all participants have jotted down their ideas prior to joining the meeting. If you don’t do this, you’ll end up wasting the majority of your meeting watching people write down thoughts while missing out on having enough time to resolve conflicts and have meaningful discussions.

The subject of your meeting, much like the subject of a Git commit is your what. Your participants need to have a clear and concise subject so they know what the meeting is for. Stick to a couple poignant words that grab the participant’s attention. Anything more means the subject matter might be cut off in notifications, reminders, schedulers, calendars, etc. which forces the participant to spend additional time inspecting the meeting in order to learn what the meeting is about.

For example, let’s say you need to have a meeting about API design. You could use API Design as your subject but API design is broad and would probably take up too much time for a single meeting. Try to narrow the scope instead. Maybe the meeting needs to be specifically around API versioning which, by the way, is not a good idea. In that case, maybe you could use API Version Avoidance as the subject instead. Now you have a short but concise subject that gets at the heart of what you want to discuss with your team.

Your meeting must always have a body. Again, much like a Git commit body, the body of your meeting message needs to explain why the meeting is important by defining an agenda with desired outcomes. For example, I’m most likely to decline a meeting without a body since I won’t be able to tell why the meeting is necessary. I assume others, who value their time, would do the same…​or at least be hesitant to accept.

To keep your audience engaged and show you value people’s time, a brief outline is best. Continuing with the API subject matter, mentioned above, we might want to include the following in our meeting body:

With the above example, we now have a clear reason as to why the meeting is important along with distinct actions and desired outcomes.

In addition to knowing the subject (what) and body (why) of your meeting, it is important to know the schedule of when the meeting will occur and the length of time it will take. Schedules are tricky to coordinate which is another reason for defaulting to asynchronous collaboration rather than coordinating everyone’s time. In small teams, this might not be so hard but in mid to large teams, schedules can get complicated quickly.

My default for scheduling meetings is usually after lunch since my circadian rhythm is at it’s lowest due to the body processing the food I ate. For others this might be the opposite or not even close due time zone constraints. Aim to schedule during the time best for you when possible. Additionally, you need to know your audience and be conscious of their optimal times as well. All of this is to say that schedules are hard and if you can avoid the meeting altogether, do so.

As for meeting length, default to 45 minutes or less. The extra fifteen minutes before the turn of the hour will give you a buffer of downtime before your next meeting should you end up in back to back meetings. Even if your meetings are not scheduled close together, short time constraints helps force focused discussions.

Finally, never schedule a meeting at the start or end of one’s day. People don’t want to be surprised by an event they didn’t have time to prepare for. At a minimum, give attendees a day’s notice unless you’ve already been talking and agree to schedule more time to discuss later in the day.

Who you invite to your meeting should be limited to key stakeholders and/or those with the most subject matter. If you must include a wider audience, then mark them as optional but do try to keep your invitations minimal. Some people might grumble or think they need to attend every meeting but they can always catch up on the meeting notes afterwards, if necessary. By the way, you are capturing meeting notes for every meeting, right? If not, we’ll talk about how to capture effective meeting notes shortly.

Always be on time or even a minute early for your meetings. The importance of this can’t be understated because whether you be the host of the meeting or the participant, showing up on time shows you value each other’s time. This goes a long way in building the bonds of trust within a team. Ignoring this will eventually devalue and erode the importance of collaborating with others. So, yes, be punctual.

Being punctual includes starting the meeting on time too. A lot of teams like to wait for everyone to show up before starting. By starting on time rather than waiting for stragglers, you reinforce a culture of punctuality and build in a penalty for those being late in the form of public embarrassment. This isn’t meant to be a malicious gesture but a dose of humility every now and then can go a long way in correcting undesired behavior.

Speaking of documenting your meetings, there should be an artifact left behind so others, who didn’t attend, can learn from or contribute too. This is where meeting notes come into play. Meeting notes are an important artifact to be produced by every meeting to keep you accountable.

A common mistake in capturing meeting notes is to produce them after the meeting, which is not a good use of anyone’s time. Instead — and especially with modern tooling — focus on capturing meeting notes in real-time. Even better, as the host of the meeting, you don’t have to be the only one capturing meeting notes. This can be done in real-time by all participants and should be encouraged or even reminded at the start of every meeting.

Here are a few tools that allow for real-time collaboration:

All of the above examples show participant activity in real-time via multiple cursors and visual updates. This visual element allows you focus on presenting ideas in your meeting while others are capturing and contributing to the collective notes for sharing afterwards.

A good template (Markdown) template to use might be the following:

…​and here’s an example using the above template:

The transparency of these meeting notes allows for a wider range of people to be informed as to what is going on within the company especially if people are out sick, on vacation, or predisposed.