This is an opinionated guide to running meetings by me. It's not the law.
Good meetings are:
- Infrequent
- Focused
- Involving as few people as possible
- As short as possible
A good meeting needs 5 things. If you don't have all five your meeting won't automatically fail, but the more you have the better it will go.
The three roles of the facilitator, the timekeeper and the note-taker should be clear and decided before the meeting starts. Ideally, the three should all be different people, but one person can play all these roles if necessary.
What is the desired outcome of this meeting?
A plan of what is going to be discussed in the meeting. All participants of a meeting usually know what they want to have heard or find out in a meeting, so get them to simply list those things at the start of the meeting, and that's the agenda. Everybody should come to the meeting with their agenda items already in mind.
One person should be responsible for directing the discussion, including deciding the order of items on the agenda, cutting short unproductive or off-topic discussion, and requesting input from all stakeholders. The facilitator should not be afraid of seeming rude or impatient; their job is to keep the meeting moving efficiently.
Another person should be responsible for making sure the meeting begins promptly, ends on time, and that too much time is not spent on one agenda item at the expense of the others.
Everything that is decided, and crucial points in making those decisions, as well as any actions to be taken and who those actions are assigned to, should be written down and distributed as soon as possible after the meeting.
Always invite the minimum number of people to a meeting as possible. Even good meetings are disruptive events that require advance preparation and post-meeting follow-up. For the purposes of planning a meeting, assume that everyone involved costs the company about $150/hour. If you have a meeting of 10 people, that decision should be worth $1500. If your meeting is missing a vital decision maker and you have to have a follow-up meeting afterwards, you've wasted $600.
These are good objectives for a meeting:
The outcome of the meeting should be a decision. For this meeting to be effective:
- A proposal for what the decision should be and why, or what the alternatives are, should be provided in advance. The meeting is for making the decision, not reading the material.
- Everyone must have all the information required to make the decision. If they don't, postpone the meeting until they do, or agree before the meeting starts that the decision must be made with incomplete information.
- The people empowered to make the decision are in the room. If the ultimate decision-maker is not present, reschedule so they can attend or get them to delegate the decision-making authority (i.e. no veto power).
- The decision made must be agreed and written down (by the note-taker, see above).
The outcome of the meeting should be to get input from stakeholders on a proposal. A meeting is helpful for this purpose because it saves time by preventing duplicate, detailed feedback on the same point from multiple sources, since everyone giving feedback can hear everyone else. Beware! This can lead to group-think. To be effective:
- All participants should have seen the proposal before the meetings
- Everybody should have their feedback prepared in advance
- As proposal owner, avoid suggesting changes or solutions "on the fly" during the feedback
The owner of the proposal should make modifications and present changes after the meeting has ended.
The goal is a high-bandwidth exchange of information between two or more teams so they can work together effectively. This meeting should involve a single representative from each team. Each participant should:
- Have detailed information about the state of their team
- Be empowered to assign tasks to that team
- Have questions prepared for the other team
If you don't have all of these, consider the alternatives in "How not to have a meeting" below. Avoid "status" meetings, see below.
The goal is to provide a large amount of information very quickly in an engaging, interactive format. Beware! This is a dangerous kind of meeting that can often be replaced by a long-form document, such as a spec or documentation.
If the goal of a meeting is for one person who needs information to go around a group and have them each provide a status update, and the participants are otherwise unaffected or uninterested in what each other has to say, cancel the meeting. This information is better communicated 1-1 or via ambient updates (see "how not to have a meeting").
Do not have "optional" meeting participants. Either you need that person to be in the meeting to make a decision or provide input, or they can be informed of the result of the meeting afterwards. If you're on the fence about inviting someone, ask yourself: am I willing to bet $150 they will have something important to say?
If there are multiple strong opinions with extensive cases to make in favor of their alternatives, this should not happen in the meeting. Like any decision meeting, proposals should be provided in advance of the meeting, everyone should read them in advance, and the meeting should be the stakeholders relaying their preferred proposal, with the final choice made by the decision maker.
If a group of people often need to meet, it's fine to have a standing time on everyone's calendar to avoid having to repeatedly schedule this, but if the meeting arrives and there are only a handful of agenda items or none at all, be liberal about canceling the meeting or cutting it short. Fewer meetings are better.
Is the decision maker not present? Are we waiting for more information? Was this standing meeting formerly useful but no longer? Has not enough changed since the last coordination meeting to require another one? Cancel the meeting.
The best way to have a meeting is to not have a meeting. Consider alternatives:
- Ambient status updates -- the #1-2-3s channel, a GitHub tracking issue
- DM/IM -- some questions are quick enough not to require a meeting
- GitHub issue -- some questions are too complicated to answer in a meeting, or require work to answer
- A project Slack channel -- coordinate asychronously across teams
- A proposal document or 1-page spec -- present a complicated idea in advance