Rands in Repose: How to Run a Meeting
randsinrepose.com
randsinrepose.com
GOALS
There are only two useful goals for most meetings:
1. Make a specific decision.
2. Determine the answer to a specific question.
If a decision is that something will be done, it should also state who will do it, and any relevant extra details such as a timescale or who else needs to be notified when the action is complete.
Before any formal meeting, an agenda should always be circulated, stating the decisions to be made and questions to be answered during the meeting. Agendas should be provided far enough in advance for attendees to organise their contributions, and to identify any agenda points that could be better addressed in a different forum.
After any formal meeting, minutes should always be circulated, stating the decisions and answers. Minutes should be available as soon as possible after the meeting, and placed somewhere they will be easy to find later. Sending the minutes for last month's meeting around the day before this month's meeting is about as useful as sending the agenda around after the meeting has started: better than nothing, but not by much.
Anything on the agenda that does not have one of the two specific goals above is probably a waste of time. In particular, agendas consisting only of vague topic headings are the kiss of death for meetings.
There is little value in holding a meeting to announce answers that are already known or decisions that have already been made. Just send the information to the relevant people to consider in their own time. If you're ever chairing a meeting and feel yourself about to utter the words "Let's go round the table...", you are probably about to make a mistake.
ATTENDEES
The participants in a meeting should be precisely those who are required to make the decisions and determine the answers.
There should also be someone to lead the meeting, and someone to take the minutes. These should preferably be separate people, so neither of them is trying to organise the meeting and participate in the discussion at the same time.
If a decision or question does not require at least the majority of the participants in the meeting, it should probably be dealt with on another occasion.
If a decision or question can be dealt with by a single person on their own authority, see "holding a meeting to announce answers that are already known or decisions that have already been made" above.
BRIEFINGS
Sometimes, it is useful for one person to share some information with a whole group, possibly with some degree of interaction or taking questions afterwards. This is fine, but if there are going to be mostly one-way briefings like this, they should be scheduled, prepared by the briefer, and presented to the group as such.
A release meeting is a good example of this. You might plan a code deployment to the production site. Before you execute it, you might have a meeting with all the stakeholders, giving them a chance to see what you're going to do. Maybe there's a person there whose only role will be to say: "hey, wait, if you deploy content before updating this other component then the images on the cdn will get screwed up." He can play iPhone games for the rest of the meeting, he potentially just prevented a partial service outage.
There's a nice theory that this could be done with email, but the reality is that having meetings and reviewing documents via email tends to turn up different issues. So doing both is helpful.
Why?
I have worked on developing technical review processes in more than one organisation, and spent many hours reading the books, studying the research and conducting practical trials. I have never encountered any evidence to suggest that everyone-sitting-there meetings are more productive than sending people copies of the material to check over in their own time and providing a sensible tool to record the findings.
On the contrary, my experience is that technical review processes often make fine examples of how to get meetings wrong. Calling a multi-hour, all-hands meeting every time something comes up for review seems to be as sure a guarantee as anything in life that your review process will fail and your staff will wind up with a permanent grudge against the very idea of reviews as a worthwhile use of their time.
That is because many issues raised during reviews are simple, and can be resolved simply and quickly between the reviewer who found the issue, the author of whatever is being reviewed, and possibly a small number of other reviewers who made the same or related observations. Making a wider group sit through dozens of typically short and bilateral discussions as you work down a list of every little point is enough to induce sleep even in the most dedicated and conscientious of participants.
Of course, there may be some issues that can't be resolved easily in this way. Perhaps discussion via e-mail/review tool/document comments/whatever is too inefficient for the number of reviewers/comments involved, or there are multiple people making related but subtly different points. This can lead to a productive meeting, but now you have both a specific point where a decision is needed and a clear list of interested parties to invite.
So have I, although perhaps I've read fewer books and run more releases.
> I have never encountered any evidence to suggest that everyone-sitting-there meetings are more productive than sending people copies of the material to check over in their own time and providing a sensible tool to record the findings.
My experience differs. I did not suggest that meetings are more productive. They are just different. Whether they will be useful to you, in particular, almost certainly depends on exactly how your organization is put together and how your software is built. And now that I think about it-- the physical layout probably matters, too.
But the pattern I've observed (for the release meeting in particular) is the following: Send out the materials in an email and get feedback. Call the meeting and review the materials-- usually about 5-10 people for 30-60 minutes. There will be completely different feedback. Both will be helpful, and both will help reduce the need for SysAdmins to escalate issues and prolong downtime.
There will be crosstalk, there will be issue resolved via discussion that everyone can understand. Sometimes, the nature of confusion about a something is best observed through tone of voice and body language. Sometimes it's all useless-- the plan was right from the beginning, and nobody has any issues.
Calling a multi-hour, all-hands meeting every time
For the example I mentioned, 30 minutes to 1 hour is usually sufficient. If the meeting goes longer than that, usually it's for a good reason and people who clearly don't need to be there will leave anyway.
That said, FWIW, I found that there is a serious danger of groupthink in a review meeting if the participants haven't each taken a pass at the material independently before that meeting. There are always "loud" people and "quiet" people, and a good chairperson will be able to moderate that effect, but almost everyone seems to latch onto a trail of thought easily once the suggestion is there. That is the last thing you want, if you're trying to get multiple points of view on something during a review. In practice, I've found that can reduce review meetings to finding essentially those basic issues that a subset of the attendees would have found independently anyway, but lose the input from others. The upside is that sometimes you will explore the issues you do find more deeply, but you could do that either way.
If you're ever wondering whether a meeting is worthwhile, do a back-of-napkin calculation to balance the reason for the meeting versus the actual cost of the meeting ("Hmmm... I have 10 people here who probably avg cost $75/hr. Is this meeting really worth $500?").
I've learned that one of the most important skills a group organizer can have is that uncanny ability to discern when to let the group go off on a tangent and when to reign things back in.
* Goal(s) being pursued in the project or relationship - it's amazing how often there's a disconnect on this subject.
* Progress since last update.
* Problems encountered.
* Action plan(s) for the future (near-term or otherwise).
* Assumptions on which these plans rest.
This G-PP-AA discussion could be occur multiple times in a meeting for different agenda items or sub-items.
Regarding the OP (with which I completely agree) - I think the problem is that some people are really talented "referees" but in some organisational structures the meeting is "run" by the senior person in the room or the person who called the meeting, who may very well be poor referees. It would be great if people recognised that So-And-So is really good at meeting herding (as I think of it) so let them run the meeting even if it isn't "theirs".
Works also for: concurrent modification of shared memory, parallel programming, distributed computing, government, laws, politics, debates, rules, exceptions-to-rules, paperwork, forms and warfare.