This thread on Twitter sparked a lot of interest, so I hope it’s useful if I publish the whole section on meetings from the upcoming revision of How to Teach Programming (and Other Things). Please see this short paper for a more detailed discussion.
Most people are really bad at meetings: they don’t have an agenda going in, they don’t take minutes, they waffle on or wander off into irrelevancies, they repeat what others have said or recite banalities simply so that they’ll have said something, and they hold side conversations (which pretty much guarantees that the meeting will be a waste of time). Knowing how to run a meeting efficiently is a core skill for anyone who wants to get things done. (Knowing how to take part in someone else’s meeting is just as important, but gets far less attention—as a colleague once said, everyone offers leadership training, nobody offers followership training.) The most important rules for making meetings efficient are not secret, but are rarely followed:
Decide if there actually needs to be a meeting.
If the only purpose is to share information, have everyone send a brief email instead, or better yet, add notes to a shared document so that people can find the information later. Remember, you can read faster than anyone can speak: if someone has facts for the rest of the team to absorb, the most polite way to communicate them is to type them in.
Write an agenda.
If nobody cares enough about the meeting to write a point-form list of what’s supposed to be discussed, or if that list isn’t circulated at least a day in advance, the meeting probably doesn’t need to happen. (Note: “the agenda is all the open issues in our GitHub repo” doesn’t count.)
Include timings in the agenda.
Agendas also help you keep the meeting moving (as in, “That’s very interesting, but we have five other topics to get through in the next fifteen minutes, so could you please make your point?”), so include the time to be spent on each item in the agenda. Your first estimates with any new group will be wildly optimistic, so revise them upward for subsequent meetings.
Every meeting is a micro-project, so work should be prioritized in the same way that it is for other projects: things that will have high impact but take little time should be done first, and things that will take lots of time but have little impact should be skipped.
Put someone in charge.
“In charge” means keeping the meeting moving, glaring at people who are muttering to one another or checking email, and telling people who are talking too much to get to the point. It does not mean doing all the talking; in fact, whoever is in charge will usually talk less than anyone else, just as a referee usually kicks the ball less often than the players. One way to ensure this is to give the moderator a stuffed animal or something else to hold up when they’re speaking on their own behalf rather than moderating.
No one gets to be rude, no one gets to ramble, and if someone goes off topic, it’s the chair’s job to say, “Let’s discuss that elsewhere.” If your project has a code of conduct (which it should), the moderator should remind people of it at the start of each meeting.
Insist that everyone put their phones, tablets, and laptops into politeness mode (i.e., closes them). If this is too stressful, let participants hang on to their electronic pacifiers, but turn off the network so that they really are using them just to take notes or check the agenda. Before insisting on this, though, please check if people need their devices for accessibility reasons.
Participants should raise a finger, put up a sticky note, or make one of the other gestures people make at high-priced auctions instead if they want to speak next. If the speaker doesn’t notice you, the person in charge ought to.
Someone other than the chair should take point-form notes about the most important pieces of information that were shared, and about every decision that was made or every task that was assigned to someone.
While other people are talking, participants should take notes of questions they want to ask or points they want to make. (You’ll be surprised how smart it makes you look when it’s your turn to speak.)
Keep a backlog.
If anything comes up that looks like it will take the conversation into the weeds, write it down on a sticky note and put it on the table (or the wall behind the moderator, or wherever else is convenient), and then deal with it at the end of the meeting. This works better than having the moderator take a note, since everyone can see the backlog piling up and compare it against the time remaining.
If your meeting is scheduled for 10:00-11:00, you should aim to end at 10:55 to give people time to get where they need to go next.
Post the minutes.
As soon as the meeting is over, the minutes should be circulated (e.g., emailed to everyone or posted to a wiki):
People who weren’t at the meeting can keep track of what’s going on. You and your fellow students all have to juggle assignments from several other courses while doing this project, which means that sometimes you won’t be able to make it to team meetings. A wiki page, email message, or blog entry is a much more efficient way to catch up after a missed meeting or two than asking a team mate, “Hey, what did I miss?”
Everyone can check what was actually said or promised. More than once, I’ve looked over the minutes of a meeting I was in and thought, “Did I say that?” or, “Wait a minute, I didn’t promise to have it ready then!” Accidentally or not, people will often remember things differently; writing it down gives team members a chance to correct mistaken or malicious interpretations, which can save a lot of anguish later on.
People can be held accountable at subsequent meetings. There’s no point making lists of questions and action items if you don’t follow up on them later. If you’re using a ticketing system, the best thing to do is to create a ticket for each new question or task right after the meeting, and update those that are being carried forward. That way, your agenda for the next meeting can start by rattling through a list of tickets.
Managing “That Guy”
Some people are so used to the sound of their own voice that they will insist on talking half the time no matter how many other people are in the room. One way to combat this is to give everyone three sticky notes at the start of the meeting. Every time they speak, they have to take down one sticky note. When they’re out of notes, they aren’t allowed to speak until everyone has used at least one, at which point everyone gets all of their sticky notes back. This ensures that nobody talks more than three times as often as the quietest person in the meeting, and completely changes the dynamics of most groups: people who have given up trying to be heard because they always get trampled suddenly have space to contribute, and the overly-frequent speakers quickly realize just how unfair they have been.
Another useful technique is called interruption bingo. Draw a grid, and label the rows and columns with the participants’ names. Each time someone interrupts someone else, add a tally mark to the appropriate cell. Halfway through the meeting, take a moment to look at the results. In most cases, you will see that one or two people are doing all of the interrupting, often without being aware of it. After that, saying, “All right, I’m adding another tally to the bingo card,” is often enough to get them to throttle back.
This isn’t the only way to run a meeting: different cultures have different conventions, and every group will evolve its own practices. If more than half a dozen people are involved in decision-making, consider adopting Martha’s Rules. If you think you need Robert’s Rules of Order, you should probably get some training in how to run and participate in meetings.