Plenty of literature and blogs exist on arranging good meetings. The scope of this blog article is limited to physical meetings in virtual organisations, i.e. collecting a group of people who work together every day but see each other once or at most twice a year. That special context puts the emphasis on certain decisions and practices, which I attempt at highlighting below.
The twelve items come in a chronological order.
Before, during and after the meeting
1. Set the right meeting goals.
- Try to solve fewer problems than you would like to at first sight, but solve them properly. Nobody benefits from reheating old ideas over and over. Everyone benefits from getting rid of issues permanently.
2. Use Wiki from preparations to storing persistent notes.
- Have one persistent, easy to access, easy to maintain storage for all meeting related information, from womb to tomb: The company-internal Wiki. This saves on redundancy: no copying between formats, no updating from here to there and back, no email attachments, no confusing old copies lying around.
- Use Wiki to prepare and plan sessions virtually before the meeting. Cut down on email.
- Encourage the use of Wiki even for presenting information on screen during the meeting. Allow Keynote, PowerPoint or Open Office Impress, but don't specifically encourage it, and by no means require it. True, "slide borders" don't exist in Wiki and a classic presentation focuses the attention on what the presenter displays at the moment. But the savings on redundancy related costs are huge, if you skip slides.
- Share notes right after the session. Mandate the scribe to clean up the notes and notify relevant people over email within 2-3 hours after the session ended. In the email, include the URL for the Wiki page, but paste the contents in acceptable format, so attendees who wish to do so can read the notes when flying home without Internet access.
- Store notes persistently in Wiki. This is useful when the action items are being worked on, put into Worklog (task management system), and reviewed at follow-up meetings. Use the store as an archive, a reference, a role model e.g. when related sessions are planned at future meetings.
3. Concentrate on Action Items and Policy Changes.
- Consider the prime success measure of the meeting to be the quantity and quality of Action Items and Policy Changes that are clearly documented as a result of the meeting. True, meetings should also set common goals, instil a fighting spirit, share information, boost morale, and be fun. But the considerable cost of flying people to one location can only be justified by getting more work done when together, rather than dispersed. And few things boost morale, instil a fighting spirit and are fun, as much as the feeling of accomplishing relevant work together.
- The moderator shall, by directing the discussions, focus on moving forward ideas over well-formed thoughts and proposals to actual action items and policy changes. And so shall the scribe, by phrasing and pointing to incompletenesses. And so shall the participants, by supporting the goal of the topic at hand and by avoiding distractions.
Before the meeting
4. Pick the right location to minimise travel cost.
- Use the cost per participant meeting day as the key performance indicator of the financial success of the meeting. Count in flights, trains, accommodation, meeting rooms, internet, dinners, entertainment, everything related to the meeting, and divide it by the number of participant meeting days. If twenty people meet for two days, and then just ten continue for another three days, we have seventy participant meeting days.
- Set the meeting date early, several months in advance. This enables cheaper flight tickets, and less hassle for attendees from Russia, the Ukraine and other countries requiring visas.
- Pick a place with some local attendees.This not only saves on travel cost, but simplifies the choice and booking of hotels and restaurants. For MySQL Dev Mtgs, good places are at least Moscow, St. Petersburg, Kiev, Helsinki, Sofia, Berlin, Vienna, Uppsala/Stockholm, Heidelberg, Munich, Paris, Dublin, Austin, Cupertino, and Seattle, in rough order from east to west.
5. Invite the right participants (only).
- Require every participant to contribute before, during and after the meeting. If they don't contribute, why go through the trouble and cost of travel?
- Don't let distance pose an artificial barrier for invitations. Although trans-atlantic flights are more expensive than flights within Europe or within the US, with early enough planning, the difference can end up being relatively small. In Berlin, we made at least one mistake on the side of being too restrictive.
- Be sure to invite guests from cooperating departments. Having invitees from stakeholder departments is both productive, revealing, and fun. In Berlin, we had three Support engineers (superb!), a Community guy (in addition to myself), and a number of Developers, in addition to the core group of QA and Build engineers. We could have done with a few more guests, such as someone from Marketing.
6. Issue a formal Call for papers to identify session proposals.
- Don't believe that you know all relevant topics yourself. The collective body of intended participants sits in with a lot of good judgement, on what you need to focus on in order to achieve the overall meeting goals.
- Require people to go through the trouble of identifying individual sessions. What topic? What should the session goal be? Who can moderate? Who should attend?
- Require the proposal to be delivered over Wiki in a predefined format. Use that Wiki page for keeping track of the session before, during and after the meeting.
- Be firm on the deadline you set for the CfP. Time before the meeting is in shorter supply than you believe.
- Iterate to improve the quality of the session proposal. Involve others, once the proposal has first been written.
7. Prepare the sessions: Require proposals for process changes, action items.
- When selecting sessions, be heavy on those involving decisions, process changes, and action items. Be light on information spreading.
- For each session, ensure that there is at least one actual proposal, if not several, prior to the meeting. Valuable face-to-face time shouldn't be wasted on stuff that could have been done in solitude prior to the meeting.
- Require people to read the proposals prior to the meeting. Again, reading is a waste of face-to-face time.
During the meeting
8. Identify moderators and scribes, support them, expect them to excel.
- As moderators, pick those who have leadership skills to keep the sessions on track. They must be able to realign the attention with the goal of the session, and know the technical topic and participants well enough in order to know when to intervene. The moderator does not have to be the best technical expert on the subject.
- As scribes, pick those who can express themselves precisely and simply in writing. They must be able to support the moderator in getting well-formed Action Items. Their subject matter knowledge can safely be on the lighter side. And if possible, they should be fast typists.
- Take even more care in picking the scribes than the moderators. People who can capture process changes, action items, and rationale in a compact, easy to understand form are in short supply.
- Reward good scribes during the meeting, by highlighting the best meeting notes. Motivate scribes (jokingly) by pointing to their power: It's their version of what was decided that is preserved for posterity, and used after the meeting.
- Educate scribes: Have a training session for scribes at the beginning of the meeting. Ask those who have already worked as scribes (in previous meetings) to share their experiences in those training sessions.
9. Use IRC for moderators, scribes and participants, throughout the meeting.
- Use IRC as an instant-messaging whiteboard. IRC should be constantly running on every participant's laptop during sessions, including the moderator and the scribe.
- Don't interrupt the moderator (or the person who is just now speaking) over IRC. It's hard to moderate, talk and keep your eyes on IRC at the same second. The moderator can read up on IRC notes, when others are speaking.
- If valuable content is being spewed out on the fly by technical experts, have the fast-typist scribe type down all of it on IRC. Don't poke fun of tyipng errrors. Encourage the technical expert to verify the notes frequently. Encourage participants to interrupt softly if wrong notes are being taken (such as by suggesting the right notes over IRC). If the technical expert is too dense and too quick, tell him to slow down. Be light on the criticism of the fast-typist scribe -- it's a stressful task.
- In normal meeting mode, require the scribe to type down much less: Suggested decisions, action items and important rationale (both pro and con). Encourage participants to help out by phrasing their suggestions directly on IRC, so not all of the burden is on the scribe.
- Have the scribe edit IRC scribblings into more final notes, when idle. And when the meeting ends officially, make it clear that the scribe is not expected to take any further notes, but should be allowed to concentrate on cleaning up the notes.
10. Spend time working together during the conference.
- Have topics prepared before the meeting, but not over-prepared. The suggested decisions should still be in a phase where the physical meeting can influence direction. A physical meeting is much too valuable to be degraded into a mere broadcasting forum, one person preaching, others politely listening.
- Set aside time for ordinary, mundane work. Not for expense reports, perhaps, but for critical solitary work where some input would be beneficial and where interruptions are OK. Short clarifications increase efficiency and boost morale in an organisation starved for face-to-face contact. "Hey, now that you sit here, can I ask you <x>?" But be sure the light interruptive questions are light, and not worth sessions in themselves.
- Require each participant to pre-plan one-on-one meetings and email their meeting counterparts about the meeting need, prior to the physical meeting. If not, you will find a lot of cursing about "Why didn't I talk to NN about <x>?" when the first participants drop off. "It would have been so easy to resolve a couple of items, had I only thought of it in advance." If you're in charge, encourage people to think in advance.
11. Set aside enough time between sessions to get the work done.
- Don't believe the session is over just because the moderator closes it. Notes have to be cleaned up, they have to be published, and they have to be reviewed. All of that takes time.
- Set aside time for scribes to properly clean up the notes, publish them on Wiki and send them out over email. The email should not be a mere notification with the Wiki URL but also contain the Wiki text, so that it can be commented upon in an email in parallel, or by people who are already in-flight without Internet access.
- Require notes to be published within 2-3 hours of the end of a session. Why? Memories have a short half-life. And that goes for the memory of the scribe, the moderator, and the participants alike.
- Set aside time for moderators and participants to comment upon meeting notes during several time slots each day. Memories have a half-life, remember.
- Be ample on the review time. Moderators and scribes are scarce resources, and they also need to sleep, eat and join at least some of the evening programme. In the meantime, less scarce resources can do one-on-one mtgs.
- Include short note review sessions. Here, mistakes can be corrected, and half-complete Action Items can be completed. For topics of particular importance, set aside time for longer follow-up sessions. Call them multiple-session topics, if you will.
- Take care, as moderator and as scribe, to involve those not present at the session. Highly relevant people, required for decisions or process changes, might have been in other parallel sessions at the moment. Or they might not even be at the meeting, perhaps staying at home in order to save the company some cost. Nonetheless, they should get the time to give their input before the next meeting day. And, if they're on another continent, they may well have prime working time at their disposal for commenting.
After the meeting
12. Follow up on action items, process changes, costs, experiences.
- Follow up that Action Items are properly entered into task management and project management systems. Ensure they are in Worklog (in MySQL's case), with proper references to the Wiki pages from the meeting.
- Follow up that process changes take effect in the corresponding process documents on Wiki, in the manual or wherever they belong.
- Follow up on decisions and action items in regular management meetings. Make sure the entire physical meeting wasn't held in vain, and initiatives keep on track!
Early in May 2007, MySQL AB will arrange its next Developer Meeting. We are still choosing between Sofia, Heidelberg, Munich and Vienna. We expect to considerably raise the ambition level from earlier meetings on Malta, in Prague and in Sorrento. In particular, we also expect to open up attendance for some external community members. If interested, please email both Lenz Grimmer (Community Relations Mgr, Europe) and myself at firstname.lastname@example.org.