Meetings are hard. When meetings are run well, the participants should come away feeling like work was done and next steps are clear, but often, people will leave a meeting feeling like it was a waste of time. People in roles where their work is done mostly independently (e.g. software developers) may especially feel that meetings “get in the way” of them doing their “real job,” and view meetings as an interruption rather than a productive use of their time. How do you, as a meeting organizer, keep all these people engaged so that you get the most of your meetings? There are three simple rules to follow:
- Set Expectations Up Front
- Pay Attention to the People in the Room, and
- Follow Through
Set Expectations Up Front
Nobody likes to receive an empty meeting invite with a generic title like “Discuss Design for Next Sprint” and no description. Discussions can be fruitful, but without a goalpost the meeting can easily wander off-topic. If you search for meeting tips, #1 is usually to have a set agenda, but in my experience it is important to go beyond this. Yes, you should know precisely what discussion topics and activities you want in the meeting, but you should also know what the output of the meeting should be. Why are you holding this meeting in the first place, and why did you include each person on the invite? If you can’t answer either of those questions, you need to consider whether this meeting actually needs to happen or if it can be an email, quick desk conversation, or asynchronous collaboration (e.g. Google Doc).
Through the rest of this post, I will describe my suggested strategies through the lens of a meeting titled “Discuss Design for Next Sprint.”
Suppose you are a back-end software developer and you received this meeting invite from your Product Manager. Included on the invite are the rest of your agile development team (front-end devs, testers, dev manager, designer), which can be easily 10 people. This meeting is booked for an hour during your most productive time of the day, so you are already a little miffed that your flow will be interrupted. Since you don’t work on the front-end, is it really that important that you be present for a meeting about what the software is going to look like?
As a Product Manager or Dev Manager, you understand that each member of the team has a unique perspective on the work to be done that could affect the design, but each team member may not realize how important their voice is if they don’t feel engaged enough to use it and see their recommendations validated. The backend dev can provide important insight on the performance of certain actions in the design: for example, whether the data structure allows for quick and easy paging of requests. If they skip this meeting or sit through it silently, key information that could affect the success of your next development cycle may be missed.
As the Product Manager for this team setting up this meeting, I would first consider why the design needs to be “discussed.” What am I hoping happens out of the meeting? Having held many such meetings in my time as a Product Manager, I typically land on this goal: gather feedback on feasibility of the design draft from the development team for the designer to use in the next iteration of their draft. By including this on the meeting invite, the developers know that they are expected to provide input and the designer knows that they are expected to present a draft for feedback rather than a final/high-res solution. It is also helpful, if possible, to provide resources up front for anybody who wishes to prepare in advance, but in most cases I expect the majority of people to not have done preparation.
Pay Attention to the People in the Room
With this goal in mind (collect feedback on feasibility for next iteration), how the meeting should actually run would be very dependent on the collection of people involved. In general, I find that teams with higher trust and psychological safety can get away with less formal structure to meetings (if they want). These teams can count on each other to provide candid, kind feedback without offense and feel comfortable steering the meeting back on topic without stepping on any toes. In this case, I would likely keep the agenda as simply “Designer presents design for next sprint, and the team provides feedback.”
Throughout the meeting, ensure notes are taken, and summarize the actions/take-aways at the end so that everybody understands their voices have been heard, and invite feedback for anything you missed.
Great meeting everyone, I wrote down that Backend Dev is going to investigate how to incorporate paged data into the design, Frontend Dev is going to check if there is already a long text input form control in our standard library, and is going to benchmark our current load times before this solution is implemented. Did I miss anything?
Teams with lower trust or psychological safety may bristle at the idea of feedback, as it can easily be interpreted as personal criticism. More structure can help to keep the conversation “on the rails.” In this case, I would guide the discussion via specific questions rather than opening the floor.
Backend Dev, what changes need to happen to our API calls to support this visualization?
Frontend Dev, how does this design align with our library of standard front-end components?
Tester, what risks do you see in this design which may require additional thought?
By asking specific, open questions related to each person’s area of expertise, criticism outside of each person’s area of expertise is kept to a minimum (for example, it is likely not appropriate for the development team to comment on how “nice” a design looks, as this feedback is non-specific and butts into the designer’s area of expertise).
If the tone in the room begins to get defensive and difficult, re-orient the discussion. When re-orienting the discussion, I typically like to start by thanking people for their input (especially whomever seems to be the most defensive), acknowledging the tone or difficulty at hand (without assigning blame), and then asking a specific question:
Thank you, Designer, for putting together this draft for us to discuss today, I can already see how this is going to make our users’ workflows much easier. It sounds like there is some concern in the room that the included animations, while delightful, may inflate our timeline beyond our target release. Would it be possible to leave out these animations for this release, and have you and Frontend Dev discuss alternatives for next release?
If this does not help to cool the tone in the room, or you need to do this repeatedly, end the meeting.
I think that we’ve gathered enough feedback for now; I propose we give everybody back our remaining 30 minutes and I’ll touch base about next steps later today.
After the meeting, it is important to follow-up with everybody to ensure that nothing is missed. Consider booking a series of smaller meetings so that the size of the group is less threatening, or collecting feedback asynchronously and privately so that you can filter it. In cases where things get particularly heated and there is personality conflict, it may be appropriate to follow any conflict resolution procedures set out by your company.
Follow Through
Finally, if you want people to keep attending your meetings, follow up and follow through. If you, as the meeting organizer, have walked out of a meeting with no new tasks or things unblocked, I would question whether it was actually important for you to be in the meeting (unless your purpose was only to facilitate). Some things that may need to be done after the meeting are:
- Book any required follow-up meetings ASAP so that there is a deadline for the tasks assigned in this meeting
- Document and communicate any decisions made
- Send notes to attendees with action items clearly highlighted so that everybody is aware of expectations
The notes you take and share are the evidence of the value of the meeting, and help attendees to remember what was discussed and what decisions were made. The notes help keep everybody on the same page. I have frequently encountered cases where a decision is made in a meeting and later the details of the decision are misremembered by different people, causing the decision to be made all over again. This wasted time could have been avoided by clear notes and documentation that could be revisited instead. I honestly can’t emphasize enough the importance of notes during meetings, and I will say it again: the notes you take and share are the evidence of the value of the meeting.
By setting expectations for your meeting up front, running the meeting appropriately for the people in the room, and always following through after the close of the meeting, even the most staunch anti-meeting people will slowly come around to see that time spent in meetings can be just as valuable as time spent working independently.