Meetings are my least favorite form of communication when collaborating with others because they tend to be an ineffective use of time when a thoughtful post, article, document, etc. could be used instead. This is especially true for knowledge workers — as the comic above captures well — when working in asynchronous environments.
Having studied a lot advice about communication and meetings, especially in the software world, I’d like to guide you through how to use meetings as a last resort, being conscious of your and others' time and attention, and providing guidance on how to structure a meeting should you need one.
Let’s start by talking about meetings that should be avoided. During the course of your career, you’ve probably been stuck in these kinds of meetings yourself — or worse, are subject to them now. The following are examples of the kinds of meetings best avoided.
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 mostly status updates. 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 are of value but usually can be addressed asynchronously without holding everyone hostage. In truth, these meetings are announcements disguised as a meeting.
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 usually result in people generating fewer good ideas rather than more. 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.
Much like company-wide announcements, status updates are another kind of meeting disguised as an informational update. These meetings usually appear as department/team stand ups 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?
Now that we’ve discussed the kinds of meetings best avoided, I’ll note that some meetings can be the best form of communication in certain situations. The following sections details what those are.
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
One on ones are meetings where you meet with your boss (or a 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 in a group setting is a good way to resolve conflicts and also have a chance to celebrate the work of others, thereby building strong bonds within a team.
Successful retrospectives do come with a caveat, which is to ensure all participants have jotted down all of 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.
So far we’ve talked about different kinds of meetings in terms of avoidances and recommendations, but we’ve not discussed how to successfully organize and conduct necessary meetings. The following guidelines will vastly improve the experience of your meetings and help you yield more productive outcomes.
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:
By now you've had a chance to read the Architectural Design Request on API Version Avoidance. For the purpose of this meeting, I'd like to get consensus on how to proceed with our API design by covering the following topics: * Handling end of life for older clients. * Handling graceful degradation of requests. By the end of this meeting, we'll have final consensus for adding all necessary stories and starting work on our epic.
With the above example, we now have a clear reason as to why the meeting is important along with distict 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.
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 produced 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 will 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:
# Subject ## Participants ## Details ## Next Actions
…and here’s an example using the above template:
# 2021-08-15 API Version Avoidance ## Participants - Brooke Kuhlmann (host) - Jill Smith - Jon Doe ## Details Discussed the various work we'll need to make our API versionless including graceful degradation along with end of life support for older clients. <additional details truncated for brevity> ## Next Actions - Jill will create an epic to capture this work along with all subsequent stories - Jon will be the lead engineering working on the implementation.
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. Such documentation and successful communication is vital to scaling. More lax approaches that may work in smaller teams cannot translate to effective communication in a larger organization.
I hope through the course of this article you have learned the do’s and don’ts of conducting meetings. In general, default to leveraging asynchronous communication in order to empower your team while falling back to scheduling a meeting as a last resort. You’ll be happier and so will your team, who will gain additional time to focus on the actual work that needs to be performed. 🎉