Good meetings

This attempts to describe some good habits for having good or even great meetings among members of the Wikimedia development community. This advice centers on consensus-oriented meetings between peers (possibly from different employers) rather than centrally-controlled meetings with a clear decision maker available to "pull rank" and make an unpopular decision over widespread objection.

Meetings are work

An old Fast Company article ("The Seven Sins of Deadly Meetings"^[1] from 1996) points out one sin of meeting organization being “People don't take meetings seriously”, and then elaborates on how people fail to treat them like work. Intel had (and probably still has) a culture of treating meetings as important work, with then CEO Andy Grove actually teaching a course on it:

[CEO Andy Grove] believed that good meetings were such an important part of Intel's culture that it was worth his time to train the troops. "We talk a lot about meeting discipline," says Michael Fors, corporate training manager at Intel University. "It isn't complicated. It's doing the basics well: structured agendas, clear goals, paths that you're going to follow. These things make a huge difference."

This isn’t to say “people need to be miserable, or we haven’t done our job”. Everyone should still enjoy their day-to-day work, and in fact may enjoy it more if they actually felt meetings were productive instead of squandering time that could be better spent on "real work".

Taxonomy

See also: Consensus

Different meetings need different conversations: make this distinction clear to everyone before the heart of the agenda. Here’s a 1999 Fast Company article about running good meetings:

For example, some meetings are built around a "conversation for possibility." The group acknowledges that it has come together to generate ideas, not to make decisions. The goal is to maximize creativity. Other meetings are built around a "conversation for opportunity." The goal is not to reach a final decision but to narrow down a field of ideas or options. You gather lots of information; you do some analysis; people take positions. Finally, there are meetings that are built around a "conversation for action." The goal is to decide, to commit: "We want to leave this room with our three investment priorities for 2000." [...]If you call a meeting, make it clear to people what kind of conversation they're going to have, and then impose a certain amount of discipline on them. Remember: Meetings don't go off topic. People do.

This seems to be the taxonomy of good consensus-oriented Wikimedia engineering meetings.

Strawman - Talk in depth about an engineering idea that doesn’t have consensus, potentially evangelizing that idea

Successful outcome: more people know about the idea, and maybe more people agree that it’s a great idea.
Successful outcome: clear definition and agreement on the problem the strawman is intended to solve
Stretch goal: consensus on the priority about the importance of solving the problem the strawman presumably solves (or consensus that it isn’t a problem after all)
Non-goal: consensus about the priority of implementing the engineering idea

Problem definition (nee Problem-solving) - Figure out what problem we're really trying to solve, and if it's really a problem

Successful outcome: consensus on the priority about the importance of solving this problem (or consensus that it isn’t a problem after all)
Successful outcome: a list of clearer problem statements that can be prioritized (e.g. if the problem is "code review sucks", emerge with a list of actionable things that suck about code review)
Stretch goal: an idea or a reasonably complete list of ideas for how to solve the problem. "Conversation for possibility" as described by 1999 article
Non-goal: a decision for how to solve the problem

Field narrowing - Narrow down choices for solving a problem, a.k.a. a "conversation for opportunity."

Successful outcome: tentative consensus about the limited set of options, with someone assigned to clearly document the tentative consensus in the consensus-building forum of record (see #Discussion of record)
Non-goal: singular consensus about the solution to the problem. This is a nice bonus outcome, but if people enter the meeting afraid that the train is leaving the station, they may position themselves on the tracks rather than being helpful participants in the field narrowing conversation.

Consensus - Arrive at rough consensus about the best solution to a problem

Successful outcome: tentative consensus on a singular most viable solution to a problem, with agreement to postpone or eliminate competing solutions from consideration. Someone assigned to clearly document the tentative consensus in an email to wikitech-l. Further advice: RFC 7282: On Consensus and Humming in the IETF
Non-goal: “Resourcing agreement”. We want to walk away from this type of meeting with tentative engineering consensus about the proper solution for the problem, but not an insistence for a real-time promise to “dedicate resources” to the proposed solution.

Education - teaching people about an idea that already has consensus and/or has been implemented

Successful outcome: more widespread interest and knowledge about an existing engineering solution, and/or recruitment of people to support/maintain/use/implement the solution
Non-goal: retroactive blessing of a controversial portion of our system

Production - working together to create something whether it is creating code or a presentation, or a drawing of several cats.

Successful outcome - something is fully created, or partially created and it is understood what needs to be done to finish the creation.

Roles

Video recording of Meeting Skills for Inclusive Moderators, by Valerie Aurora.

Meeting Skills for Inclusive Moderators slides.

Valerie Aurora gave a talk called "Meeting Skills for Inclusive Moderators" based on her experience running AdaCamp unconferences with Mary Gardiner. In the blog post "Running your unconference discussions effectively: AdaCamp session role cards", she and Mary Gardiner advise (based on Intel's meeting skills):

Thus, we encourage the discussion groups at AdaCamp to watch out for unproductive derails, and to appoint four people in each group to different roles for the length of a session:
a Facilitator, who presents the topic and keeps the discussion moving forwards

a Gatekeeper, who keeps the discussion productive and empowers people who haven’t spoken up to make themselves heard

a Timekeeper, who keeps the session to time

a Note-taker, who makes notes on the session

During the "Meeting Skills" talk, Valerie and the audience spoke about other potential roles in the Wikimedia engineering context:

Reporter, who communicates the conclusion. May be especially important in unconference-style discussions where ownership isn't clearly defined
Advocate, who ensures balance in conversation, making sure that quiet/introverted people still get heard (similar to the Gatekeeper role)
Online voice - in hybrid in-person+remote meetings, having someone available to interject on behalf of remote participants may be important

Note taking

One important product of a good meeting is good notes. Here's some suggested ways of doing good collaborative note taking.

Detailed notes (owned by the "note-taker")

The "note-taker" often performs the role of a court stenographer. When we have someone who isn't a typical participant as "note-taker", they often just want to capture "everything", and then sort it out after the fact. For important meetings, this is incredibly valuable and we often appreciate this. Stenography isn't required for every meeting, but we shouldn't preclude or discourage it either. The note-taker should own the "detailed minutes" section, and everyone else should feel comfortable helping the note-taker ensure the accuracy of this section.

Summary notes (owned by the "facilitator")

possibly in conjunction with the "reporter"

Having a competent note-taker then helps the facilitator. The facilitator can own the "summary notes" section, which should strive to be an NPOV account of the meeting. Since the answer to "who called this meeting?" is often expected to be the facilitator, the meeting will work best if they ensure we do the work outside of the meeting time.

Before the meeting: the facilitator can/should prepopulate the "summary notes" section with the anticipated structure of the meeting, using that as the working agenda for the meeting. They should put hyperlinks to important information that will likely be discussed in the summary notes.
During the meeting: the facilitator can help structure the conversation by capturing "what question are we trying to answer?" Save the synthesis of the answer for after the meeting; just synthesize the question. For some facilitators, this style of note-taking can help the facilitator pay attention to the conversation, without distracting from understanding the speaker's answer. It can be easier to ensure that the real-time notes are NPOV, since a question is much easier to make NPOV than an answer
After the meeting - in order to generate notes that are useful for people that weren't able to attend, it is helpful if the facilitator (or the "reporter" if that role was assigned/taken) generates a summary of the discussion, using the questions generated in real-time during the discussion as an outline for what was discussed. The summary should try to be NPOV, striving to report which questions seemed to have consensus, and which ones were still divisive.

Agenda (owned by the "timekeeper")

With the "summary notes" section prepopulated with the hyperlinks and background information, the agenda can be much shorter, and just focus on the time slots of the meeting. This gives the timekeeper a very simple job of making sure that the discussion is on track to complete in the amount of time allotted for each topic.

Products of the meeting

In order to make meetings more actionable (sin #4), consider creating four things to report out of a meeting:

Goals
Questions
Actions
Decisions

This is based on the format used in the 2018 Wikimedia Technical Conference.

Discussion of record

In our consensus-oriented environment, it's important that people who have a stake in the outcome of a conversation understand what happened. Many governments have established a newspaper of record as a legally-acceptable means of making important announcements when that is required. Our work shouldn't rely on publishing announcements in our paper of record (whatever that is for us), but we should have a means of making important announcements in a way where stakeholders can be effectively informed, and intervene at the appropriate time.

This may mean engaging in the appropriate discussion forum of record for both the announcement of the meeting, as well as providing the minutes. For Wikimedia software, the wikitech-l mailing list seems to be the norm, but as of this writing (January 2016), it isn't official.

References

[1] ttp://www.fastcompany.com/26726/seven-sins-deadly-meetings

[2] ttps://www.cnbc.com/2019/10/14/jeff-bezos-this-is-the-smartest-thing-we-ever-did-at-amazon.html

[1]

[2]