Mastering 7 Common Workplace Meetings [Part 1]

Not all meetings are created equal. Some meetings are more structured, some are less. Some have more attendees, some have fewer. This article investigates how to effectively run all-hands meetings, engineering meetings, product meetings, and interdisciplinary team meetings.

Mastering 7 Common Workplace Meetings [Part 1]

Not all meetings are created equal. Some meetings are more structured, some are less. Some have more attendees, some have fewer. With all of these variables, it can be challenging to differentiate the different kinds of meetings that you attend - particularly if you are always working in one team. More importantly, the strategies used often for one meeting won’t work for the next. For example, you’ve undoubtedly heard about the importance of bringing an agenda to your meetings in order to be prepared and productive right? Imagine yourself bringing a detailed agenda to a product demo with a stakeholder, or a one-on-one with your boss, or even to a 5 minute morning standup. In these cases, it makes little sense to sketch out a detailed purpose, objectives, agenda, minutes, and action items for quick or ad hoc meetings. However, preparing rigorously for board meetings, all-hands meetings, and decision making meetings is a great idea, as this preparation is how you ensure that everyone’s time is well spent and goals are reached.

So what’s the deal - how do you know how to prepare for your upcoming meetings? The first step is to understand that a meeting is not a meeting is not a meeting. Meetings are wildly varied and should be treated as such. So the first step is to find out what kind of meeting you are about to have. There are many great articles out there about the different kinds of meetings that exist, breaking down meetings into categories and subcategories. This article will focus on something a little different, however, grounding these meeting types to specific meetings that you might experience in your workplace. We will cover 7 different classes of meeting over the course of two blog posts, with details about how to prepare for them, what to expect, and what to achieve at the end of each meeting.

1. All Hands Meetings

Type: Broadcast

These meetings exist to divulge important information from management to employees and are often run by either one - or a small group - of individuals who present information to the rest of the group. These meetings have a rigid structure with a definitive start and end time and a preset agenda. The purpose is to divulge information about a pre-determined subject to a large number of people. If you are attending such a meeting, there is little involvement needed on your part. You may have the opportunity to ask questions about the material presented, but apart from arriving informed about the overarching topic of the all-hands (ex. new company initiatives, last quarter’s results, etc.), there is little preparation needed as an attendee.

This is not the case if you are running the meeting or presenting. Meeting organizers must have a structured meeting purpose, objective, and agenda (with strict time allocation for each item) well before the meeting. The presenters should be informed about when they are speaking and how long they have as far in advance as possible to allow them to prepare adequately. As a presenter, you should aim to divulge your information in such a way that everyone at the organization would be able to follow along, no matter the department or level of experience. If necessary, it is also a good idea to send out follow up material to meeting attendees with any announcements or useful information provided at the meeting for future reference. Notably, this is one of the few types of meetings that does not need specific action items. The material presented will often be so broad that there are no individual objectives to set for attendees. Once the relevant information is expressed and internalized, the meeting’s purpose has been achieved.

2. Engineering Meetings

Type: Idea Generation / Problem Solving

Engineering meetings are your run-of-the-mill technical team meetings held in order to tackle problems with a broad scope - one that may affect the future of the product - or held to ideate and innovate. Attendees to this meeting are determined by how necessary their contributions are to the actions produced by this meeting. For example, if your development team has split up to work on different parts of a larger project and the purpose of the engineering meeting is to figure out how to streamline a certain user experience, then team members focusing on infrastructure do not need to be present. Keep in mind that time spent in a meeting is time that could have been spent working on the product, so make sure that you invite only the people necessary to come up with the best solution.

Though the topics of discussion in this meeting may seem ad hoc and loosely governed, meetings of this type should follow the following basic structure: First, a problem is presented to the team. This could be the next major feature that needs to be implemented or an urgent issue that must be addressed. This presentation is often conducted by the team’s project manager or product owner as they should always have the oversight of the issue needed to instruct the rest of the team about it. The next section of this meeting is spent in active discussion and white-boarding within the team. Idea generation and problem-solving work best when the whole team is participating and suggesting solutions, not when one person is coming up with something that they feel is the best option (why even have a meeting in this case!). As the meeting draws to a close, make sure to review the main ideas/solutions that were brought up, vote on preferred ideas if necessary, and then record action items with attribution to attendees for who will do which tasks following the meeting. Coming up with new ideas and solutions is great and valuable, but ensuring that they actually get implemented is critical as well. The outcome of this meeting should be a list of the main ideas covered during the meeting along with a set of action items distributed to their relevant engineers.

3. Product Meetings

Type: Progress Check / Decision Making

Product meetings can vary significantly based on the culture of the organization in which they are held, but they often fall into two categories.

First, Progress Checks. At a progress check, product owners run the meeting, providing all of the information needed to catch everyone up to where the current project currently stands. This involves discussing how things are moving along: is everything on schedule or are certain parts of the project are behind schedule? If so, what is being done to mitigate this issue and bring everything back up to speed? The attendees of these meetings are often people working in the product owner’s team, other product owners or higher-ups like VPs of Product. Though there is room for discussion during these meetings, a prepared and solid agenda is needed for everyone involved to get a turn explaining their part. If everything is progressing smoothly, there are few action items that need to be recorded at this meeting. However, if certain projects are behind or not to spec, curt discussions can produce a few follow-up items that should be recorded and addressed as soon as possible after the meeting.

Second, Decision Making meetings. Here, the structure is rigid and to the point. As a product owner, you should begin by designing an agenda aggregating the decisions and sign-offs that you need in order to continue work on your product with no delays. Next, based on these agenda items be sure to invite the key decision-makers who are able to address your questions directly and give the go-ahead for certain projects or proposals. Often the decision-making team that you will meet with will be common throughout your product meetings, but if each agenda item needs the sign-off of only one other person then consider contacting them directly as opposed to bringing everyone to a meeting where they are only needed for a few minutes. Though it is of paramount importance that you get through all of the agenda items in the allotted time, make sure to leave room for discussion after each item. Depending on the scope of the decision, it may not be clear what the best path forward is without some conversation. As a product owner, you are also strongly encouraged to bring - or send out beforehand - any supporting material that you need to convey to decision-makers should the meeting attendees need additional information to be fully informed.

4. Interdisciplinary Team Meetings

Type: Idea Generation / Workshops

Interdisciplinary team meetings don’t happen at every organization but they have the potential to greatly expand the novelty of your team’s brainstorming or ideation meetings. Sid did a good job explaining the importance of diversity of thought in the previous Back to the Basics article with examples of how keeping up with individuals who are not directly involved in your project can help you gain insight into better solutions for your work as well. The structure of these meetings then becomes similar to that of engineering meetings discussed above, beginning with a problem or new feature by the project manager or product owner, continuing with engaged discussion from all attendees, and terminating with a review of the ideas presented along with written action items specific to individual team members. So, people leading these team meetings should be sure to come prepared with an agenda and assign a minute taker to capture the main proposals discussed during the meeting.

But how do you select who should attend this meeting? As the purpose of this meeting is to attain insight into a problem that your team may have either been stumped by or developed an answer that they are unsatisfied with, a good rule of thumb to follow is to bring in an external team that is not working directly on the same project as your team, but still has a general knowledge of the concepts required to make a meaningful contribution. For example, while it would make sense to bring together two development teams both focused on different products, it would not make sense to bring together a development and sales team if the purpose of the meeting is to solve a technical issue. Similarly, if the purpose of the meeting is to create a more effective sales script, developers may be ill-equipped to assist, effectively wasting the time of both teams involved.

Choosing a problem or point of discussion for an interdisciplinary meeting can also be challenging. Often the most effective engineering meetings are ones that focus on a single issue and help flush it out, considering many possible solutions before settling on the best one. A common mistake in orchestrating engineering meetings is attempting to solve too many problems in one session, one after the other. The same logic goes for interdisciplinary team meetings. There are two possible solutions to this problem.

  1. Present one problem from one team for everyone to attempt to solve together. This method allows you to fully address the problem at hand instead of needing to divide everyone’s attention. If you select this method then be sure to alternate which team gets to present a problem every following interdisciplinary meeting.
  2. Alternatively, you can take one problem from each team and clearly time-box each at the beginning of the meeting so that two problems are addressed and both teams walk away with useful insights. Be careful to enforce the time-boxing for both teams though or it might seem unfair to the attendees who only had 10 minutes to talk about their problem when the other team had 50.

Lastly, though interdisciplinary team meetings can be invaluable for identifying new insights, holding these meetings too often is quite costly as many members are present and if ideation meetings are not moderated and kept on task, a lot of time can be wasted. A good alternative to interdisciplinary full-team meetings is to bring in one or two ‘specialists’ to your team’s ideation or problem-solving meetings to hear their thoughts if it is not feasible to combine both complete teams for the duration of a full brainstorming meeting.

Thank you for joining us for part one of our discussion of “Mastering 7 Common Workplace Meetings.” Next time we will take a focused look at common meetings you might encounter in an Agile-based project management system. This article is also the third instalment in our Back to the Basics series on meeting productivity. Subscribe below if you would like weekly insights delivered straight to your inbox!