It shouldn’t be surprising that as a manger, you have a lot of meetings. There are the organization wide meetings, syncs with other managers, staff meetings, 1:1s, project meetings, etc. One thing I’ve tried to do (and struggled with quite a bit) is running efficient meetings with my team. I’ve gotten reasonably good feedback from my meetings, but at the same time, I’ve felt that I would have liked to have gotten more out of the meeting. The vast majority of the time, a less than stellar meeting is simply due to a lack of preparation on my part. The product of that preparation is the agenda.
What makes a good meeting agenda?
I’m sure someone else has written a great book about this topic and concisely defines what a good meeting agenda is. At the same time, I think the need for meeting can be radically different depending on the focus of the organization and how that org works. For example, I work 100% remotely on services that are subscription based and involves a very deep technology stack. If I worked in an office at an Industrial Engineering firm, meetings are likely very different beasts.
With that in mind, here are some questions I want to answer in my meeting agenda.
- What topics will be covered?
- What is the goal of the meeting?
- What context is necessary to contribute?
I usually try to write up my agenda in a simple format.
- Intro summarizing the purpose of the meeting
- Ordered list of topics to cover (sometimes with time box estimates)
- Closing paragraph defining any outcomes or deliverables expected from the meeting
Sometimes the intro or closing can be multiple paragraphs, but the structure is typically the same.
The Intro
My intros typically are there to clearly identify why we are having a meeting. This ends up being a barometer for me to understand if the meeting is really going to be helpful. When the meeting intro starts with “Lets sync up on X”, there is a good chance it is not a critical meeting. If I can clearly say “This meeting is to make arguments for option A or option B for project X”, then it is much more likely to be a good meeting.
The intro also serves to entice folks to want to actually attend. While I’m sure some organizations require attending all meetings, it is certainly feasible that someone has higher priority work. That being the case, the intro should help make a case that the meeting is worth the person’s time.
I should also mention that since most of the company is remote, there are times meeting intros are pretty generic. The reason is that not all meetings need to be exceptionally efficient. It is helpful for the team to hop on video and just hang out for a bit without much structure. For my team, this has worked out well, but you should be cautious as some people may not enjoy this sort of team building. In a remote setting, it is important to find ways create “water cooler” conversations that help build trust within the team, so I’m OK doing that in meetings sometimes.
The Topic List
The topic of the meeting really starts with the meeting title. The title should be short enough while still providing enough context so the person knows what it is about. Much like the intro, I try to avoid things like “$project sync” that don’t really communicate why you are having the meeting.
In the actual meeting description, I keep an ordered list of topics. This helps to ensure we cover the critical aspects first. Often times we’ll need to set the context in a meeting by having some key stakeholders give a quick overview of whatever the meeting is about. I will typically add a time limit to those topics in order to make it clear we shouldn’t spend the whole time getting everyone up to speed. If there is a specific person that should be leading this portion, I’ll add their name as well.
The topic list should also help recognize when a meeting might be trying to cover too much. Similarly, a lack of topics or too general topics could be a signal that there is more prep work to do before actually meeting. There are also times where you don’t want a topic list in order to keep things open. One on ones are a good example where if there is a set of topics to talk about, it likely exist somewhere else. For example, I do keep general “sync” meetings on my calendar that aren’t well defined in order to have some water cooler talk.
The Outcomes
Lastly, I like to write down a simple set of goals for the meeting and what will the outcomes should look like. It is not enough to say “get alignment on $project” because what does that even mean? Instead, I’ll try to summarize the goals and tie those goals to specific deliverables that we can all walk away with. In a remote company, finding alignment and getting people on the same page is important, but without some actual product or outcome, you can’t really be sure you are all on the same page. For example, working on cross team efforts, we might have sync meetings with the goal to sync up and the outcome being next steps defined in Jira tickets.
As it can be difficult to come up with concrete outcomes, I have a few go to targets to help the process. The first is some set of tickets that describe some work. This makes sure we’ve captured any action items or new work in addition to writing down the decisions. Another outcome I’ve often used is a document or spreadsheet that outlines some plans or goals. For example, an architecture document might be a typical outcome when starting a new project. Lastly, a future meeting agenda might be a good outcome. Many times it can be difficult to make decisions as a group. One method to help the process along is to meet and decide who is responsible for some decisions. The outcome of this sort of meeting is likely to be another meeting where the responsible person drives the decision making or planning.
Whatever the outcomes you define, the two important things to remember are:
- Who is responsible for the outcome?
- What is the concrete deliverable that can be expected by the folks in the meeting?
Agreements in a meeting are pointless if you don’t codify that decision in some system.
Final Thoughts
Some people really don’t like meetings and a good agenda doesn’t fix that. Meetings often get a bad rap because they interrupt work and can feel pointless. While I agree the rule of thumb to avoid meetings is likely a good one, I’m also OK with semi-unstructured meetings within a team when people are remote. Working remotely can leave you feeling pretty lonely at times and make it hard for a team to gel. Some people don’t come across very personable in remote meetings. They might not use their camera or simple are quiet. Having these less useful meetings gives the team time to practice and learn the social cues in a safe place, in addition to giving folks time to learn about each other. For me, while I want to make sure I’m a good steward of people’s time, I also cherish the opportunity to get to know everyone better on my team.