

Rands in Repose: How to Run a Meeting - filament
http://www.randsinrepose.com/archives/2010/08/19/how_to_run_a_meeting.html

======
Chris_Newton
There's a lot of useful advice in that article. Having organised my fair share
of meetings, I offer the following related thoughts...

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.

~~~
Goladus
3\. Review a subject with stakeholders to turn up issues and questions you
didn't know about before.

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.

~~~
Chris_Newton
> 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.

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.

~~~
Goladus
> 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.

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.

~~~
Chris_Newton
It seems our experiences have been quite different, but such is life. I'm
certainly not claiming that there is _no_ other valuable use for meetings than
making specific decisions or determining the answers to specific questions.
The briefing-style meeting I mentioned before is another kind of event
entirely, and so is a review meeting of the kind you're describing. They
should be conducted accordingly.

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.

------
eitally
My own pro-tip (just because it isn't stated explicitly elsewhere): be very
careful to limit your audience. Even inviting one extra person can "break" a
meeting. Coincidentally, it also costs more $ in lost productivity.

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?").

~~~
tjpick
Tom DeMarco in "The Deadline" presents the idea that for each meeting you
could look round the room and excuse someone to get back to work. Whoever
would most benefit from getting back to work rather than being at the meeting
- let them go.

------
knieveltech
100% of the material presented here is also totally relevant for user group
organizers. Nothing sucks worse than watching from the sidelines while a
couple of kooks turn a developer group meetup about community building into an
hour long rant-fest about how Salesforce integration is a rampaging pain in
the ass.

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.

------
dctoedt
Lots of meetings should have at least a minimal "G-PP-AA" sync-up discussion
on the agenda:

* 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.

~~~
mkramlich
Sounds smart, but looks like mainly apply to status meetings, not to all
meetings. But good stuff.

------
adn37
Btw, if you don't want people to disconnect, plan breaks regularly. I've been
in 3h+ meetings, given no break, and sooner or later someone disconnects.

~~~
frossie
Good grief, 3+ meetings aren't meetings, they are work sessions. Not only you
need physical breaks, but you do need mental breaks as well (like allowing the
conversation to drift to some light-hearted off topic banter for a bit).

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".

------
Goladus
What I like most about a meeting is when it's with a customer of mine and they
have an opportunity to explain verbally what's important to them and why.
Often I will have a number of requests, a few of which may be critically
important for reasons I would never think to ask or make an item on an agenda.

------
mkramlich
Like many other things in life the #1 rule of meetings is to try hard to not
have meetings.

Works also for: concurrent modification of shared memory, parallel
programming, distributed computing, government, laws, politics, debates,
rules, exceptions-to-rules, paperwork, forms and warfare.

