Why does this meeting exist?

A group of people with laptops sitting around a rectangular wooden table.

Meetings have a bad reputation. This isn’t the fault of the meetings; it’s more that we’re just bad at them. One thing that people tend not to like is the way that meetings slowly grow to consume one’s entire day. It’s like calendar kudzu.

Why does this happen? It’s a natural side effect of organizational dynamics. People want to be informed of — and have a chance to give input on — decisions that affect them and their work. Since these decisions often happen in meetings, folks naturally want to attend so that they don’t miss out. So they go to the meeting just in case.

Sometimes you can solve this by publishing an agenda ahead of time. Others can look at the agenda and decide if they care enough to attend. But there’s a more fundamental question that can help: why does the meeting exist?

The answer should be a sentence or two that describes why you scheduled the meeting. If you can’t answer that succinctly, you should consider what that implies.

Once you have the answer, it is wise to include it in the meeting description (e.g. on the calendar invitation) and to give a reminder at the beginning of the meeting. This is particularly helpful for long-standing meetings. Just because everyone knew the point of the meeting when it was first scheduled, that doesn’t mean that people who come into the team years later do.

For example, I include text like the following in every Fedora Prioritized Bugs meeting:

#topic Purpose of this meeting
#info The purpose of this process is to help with processing bugs and issues found during the development, verification, and use of Fedora Linux.
#info The main goal is to raise visibility of bugs and issues to help contributors focus on the most important issues.
#link https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/#_process_description

This gives a quick reminder of the overall purpose of the meeting, with a link to more information. Note that it doesn’t list which bugs will be discussed in the meeting. That’s the agenda’s job. It’s there to remind everyone why there’s a meeting to make an agenda for.

To really make it great, you can also include information about who should attend — and who is welcome to attend if they’d like. My friend Laura Hilliger included this example in her article “5 Practical Tips for Working Openly“:

This weekly meeting is for members of the diversity & inclusion working group to make decisions based on proposals raised ahead of time. We aim to include not only representatives from our NGB, but from other NGBs, and our community.

Why do this? People might not realize they’re welcome in a meeting. If a meeting is for the project steering committee, can others join? The committee might say “yes, please! We need your input!” But if the rest of the project doesn’t know that, they’ll probably stay away. Then everyone loses out.

This post’s featured photo by Christina @ wocintechchat.com on Unsplash

Ben is a principal program manager at Red Hat, focused on the Fedora Project. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: