Making Meetings Quick and Effective

Editors featured this post on Gamasutra.com

Most every team that I’ve ever worked with hated meetings. They viewed them as a counterproductive waste of time where lots of people talk, everyone smiles and nods, then each person goes back to his or her desk wondering what they were supposed to get out of attending the meeting. Unfortunately, as producers, project managers, and team leads, it’s our job to call those meetings. Furthermore, it’s our job to make sure that everyone attends both physically and mentally. In order to achieve that engagement we must make the meetings as concise and informative as possible.

Step 1: Do we need a meeting?

As much as people dislike meetings, it surprises me how often I receive requests to organize them. The first question I always ask when a team member asks me to organize a meeting is whether or not the meeting needs to happen. Often, if the meeting is simply a status update for the whole team, e-mail or instant messenger is a better solution. Sometimes, the desired meeting is really just a one on one conversation where only the lead or one representative of the whole group needs to be involved. For example, if my game designer wants to have a meeting with the whole art department to give feedback on the look of an area of a level, I suggest that he have a one on one conversation with the lead artist instead.

Always keep in mind the responsibility matrix that applies to the issue at hand: who needs to be responsible, who needs to be accountable, who needs to be consulted, and who needs to be informed. If someone only needs to be informed, send them an e-mail rather than pulling them into a meeting. Developers respect their producers more if they aren’t called into meetings that they don’t need to attend.

Step 2: Develop an agenda—what is the meeting for?

Once you’ve established that there needs to be a meeting, and before the requestor walks away, try and get a clear list of what the meeting needs to accomplish. I’ve found it useful to phrase the question in terms of action items that the requestor wants accomplished. If the requestor cannot clearly identify these action items, try to return to step one!

Use the action items to develop an agenda for the meeting. If you’re able to give it out before the meeting, an agenda is useful to attendees so that they can arrive prepared and know the flow of the meeting. I find it useful to go one step further and assign times to each individual item on the agenda to time box issues and avoid unfocused discussion. The agenda provides the added bonus of keeping you, as the manager, focused and on task while running the meeting. Some managers I’ve worked with also print out the agenda and distribute it to keep the whole room on track, especially for longer meetings.

Some meetings are very spur of the moment in game development, and there isn’t time to develop a formal agenda. In this instance, I still find it useful to take a moment and write out a shorthand agenda in my notebook. I’ve discovered the hard way that if I don’t take time to minimally organize my thoughts, I allow meetings to wander more than they need to.

Step 3: Invite Attendees

If the meeting doesn’t need to happen right away, I like to e-mail out the agenda with my invitation, and then follow up in person soon after if I don’t receive a response. For example, I invited my leads to a meeting on a recent project with the following e-mail:

Hello everyone,

Mike and I would like to hold a design meeting tomorrow from 12:30 PM to 1:00 PM to discuss the following:

• Weapon Functionality (20 minutes)
• Hazard Brainstorming (10 Minutes)

Please confirm that you’re able to attend and let me know if you have any questions.

Best regards,

Max

The key is to keep the e-mail as concise as possible. In this particular instance, we had all discussed the idea of a meeting, and everyone was already familiar with the items. You may need to give more detail if you’re introducing a new topic. Always keep in mind that effective managers avoid wasting time, and that includes wasting time asking the attendees to read a long e-mail.

Of course, if the meeting needs to happen now, then you likely need to go and personally invite all attendees. If possible, try to give them a few minutes to find a stopping point, and always reassure them that you plan to keep the meeting as short as possible.

Step 4: Set Up and Run the Meeting

When it comes to actually running the meeting, it’s good practice to arrive at least ten minutes early. The extra time allows you to prepare both yourself and the room for a quick and effective meeting. If there aren’t enough chairs, you have time to fetch some from another room nearby. If there is a whiteboard, you can write up the agenda for the meeting for easy reference. Or, if you printed out hard copies, you can distribute them to each seat in advance so that they are readily available as attendees arrive. Above all, take a moment before everyone else arrives to envision how the meeting should run—especially if the meeting involves a complicated or delicate topic.

When the meeting begins, welcome everyone and review what the requestor’s goals are, which often leads into reviewing the agenda. Then don’t waste any time before prompting discussion on the first agenda item, probably starting with the requestor. As discussion begins, start taking notes—everyone relies on the meeting organizer to remember what they said!

As the meeting unfolds, it’s important to make sure that everyone gets a voice in the proceedings, and that no one voice dominates the conversation. For example, in the design meeting referenced above, the game designer and the lead level designer were both exuberant about each possible idea, and were happily feeding off of each other’s’ enthusiasm. Since these issues possibly affected other departments, I periodically needed to jump into their conversation and politely redirect the focus toward either the lead artist or the lead programmer to ensure they had turn to weigh in. While there are many different strategies to redirect conversation, I find that I am good reiterating back to the speaker what I think their major points are, making sure that I understand correctly, then taking the opportunity to ask another participant what they think of the issue.

The next challenge is to ensure that discussions remain within the allotted time. Sometimes the discussion wanders and repeats previous points, in which case I find that reiterating the major points and asking for objections often helps push forward. Other times, such as the design meeting above, the participants get too excited and could easily keep talking for hours. In this instance, I ask to move the conversation to a follow up meeting, or encourage a one-on-one meeting afterwards, depending on the topic.

As the meeting draws to a close, I find it helpful to reiterate what the meeting accomplished, and remind people of any action items that emerged from the meeting. For my design meeting, I listed off various ideas I’d taken notes on, and charged the game designer with taking our various ideas and creating a coherent design, and reminded the lead programmer to research a piece of technology that would determine whether or not we could create a certain kind of hazard.

Step 5: Follow Up

The final step to a successful meeting is to make sure that the attendees follow through with their action items. I’ve found that there are many different ways to accomplish this task, but the most reliable I’ve found is to give attendees some kind of written record of the meeting and its results, usually through e-mail. This record is especially important for any decisions that the group made, such as cutting a feature or modifying functionality. As you compile the notes for any decisions, make sure you capture the why of the decision. It’s simple to look back in four weeks and remember that you cut a feature, but why you cut the feature might be a bit more difficult to figure out!

I still haven’t met a developer who enjoys going to meetings, but I have found that as long as you respect their time and make them feel like the meetings accomplish something, developers will be much more willing to sit down and have discussions and make decisions.