Meetings are an inevitable part of business but they are costly. Everyone involved has to take time away from their work day to participate. Having no process in place for conducting meetings practically guarantees wasted time.

 Meetings are a medium of work. People’s time is highly valuable so all meetings should be purposeful and well executed according to its type … both too few and too many meetings create waste.

Andrew Grove, “High Output Management”

Our meetings at SharpestMinds used to be poorly planned and unorganized. Research and experimentation has since brought us to a highly effective meeting structure.

Below is an outline of our approach to strategic, mission-oriented meetings: meetings with the purpose of reaching a decision. As opposed to regular, re-occurring meetings (staff meetings, performance reviews, one-on-ones, etc.).

0. Avoid it if you can

Can you make the decision right now in under 5 minutes?

Then make the decision now and move on.

Could this be an email? Is it a minor decision that just needs approval? Is it a low-priority decision with a far-future deadline?

Then it can be handled asynchronously. Send an email and move on.

1. Every meeting needs an “owner”

The meeting’s owner should be the person closest to the decision, with the most background knowledge or direct experience. If it isn’t clear who this is, someone needs to step up and take ownership. If nobody steps up, then you should.

The owner is responsible for setting the time and place and inviting the right people. This means sending calendar invites ASAP. Always send a calendar invite. If nobody knows about the meeting, it’s the owner’s fault.

The owner creates a meeting document. This should describe, in as much detail as possible, the decision that needs to be made, why it needs to be made, and the relevant background information. This document should be distributed to all the meeting participants well before the meeting. We use Google Docs for this, and are constantly iterating on the format of this document.

2. Share and read the meeting doc in advance

Because the meeting doc is shared ahead of time (ideally the day before), all participants have time to read it, reflect, and contribute. This lets the unconscious mind ponder on the decision a while, leaves time for a bit of extra research, and provides time for everyone to add their own thoughts and background knowledge.

We have an informal rule that if it wasn’t written in the doc before the meeting, it should not be discussed.

3. Read and comment silently until everyone is up to speed

We start every meeting in silence. Everyone opens the meeting doc, reads it, and adds comments. This can take anywhere from 2 to 20 minutes. Let it end naturally. Comments will turn into threads between participants and continue until every thread has reached a natural end-point or seems to require more nuanced discussion.

Quite often, most of the hard work is done in this step. It has the effect of pruning the things that actually need to be discussed, and the action items are usually pretty clear before anyone says a word. Some typical threads might look like:

"I've noticed that Z is causing problems for our users." 
=> "Noticed that too. Z was a bug and a fix has already been pushed." 
=> "Got it! Thanks"

"We should try X." 
=> "Didn't we try X already?" 
=> "Yes, but this time Y and Z are involved." 
=> "Got it. In that case, I agree with doing X again."
=> "Agreed. I can take this task."

"Do we have the data on Y?" 
=> "Yes, but it's not compiled. I can take that on." 
=> "Great, thanks."

The first thread prevented us from discussing an already solved problem and the remaining two ended with agreed upon action items. By holding most of the meeting in writing, you end up reducing the time discussing irrelevant things (dead-end threads), and greatly reduce the risk of going off on tangents.

4. Keep it on topic and call it when it’s done

The owner should take responsibility for keeping the meeting on track. This means guiding the conversation towards a concrete decision. Watch for off-topic tangents and unchecked speculation. In fact, everyone in the meeting should try and enforce this. The person who interrupts a segue with, “Sorry, this conversation is a distraction. Take it offline,” is a true hero.

Further more, you don’t need to use the full allotted time. If the decision and action items are clear, write them down and end the meeting. Don’t dawdle. When you feel like you need to use more time, it’s very tempting to start bringing up tangentially related, or completely unrelated, things. This is a bad habit. Remember: if it wasn’t in the meeting doc, it’s not up for discussion.

It’s […] unfortunate that meetings are typically scheduled like TV shows. You set aside thirty minutes or an hour because that’s how scheduling software works (you’ll never see anyone schedule a seven-minute meeting with Outlook). Too bad. If it only takes seven minutes to accomplish a meeting’s goal, then that’s all the time you should spend. Don’t stretch seven into thirty.

David Heinemeier Hansson and Jason Fried, “Rework”

Another thing that can stretch the meeting length is when a minority of participants disagree on an action item. It’s important to voice your opinion but if, despite your arguments, there is consensus from everyone but you, accept the decision and move on. Not everyone has to agree with the decision, but everyone has to agree on the decision. Don’t delay consensus (and the end of the meeting) to protect your pride.

5. Reflect at the end

Take five minutes at the end of every meeting to write what you liked about it and what you wished was different (inspired by a tweet by Justin Khan). Every participant should do this in the meeting doc. Once all have written their feedback, read it as a group and discuss anything you can do next meeting to improve things.

This might be the most valuable part of the meeting. This is the feedback that will inform how you iterate on your process. This is how you identify bottlenecks, inefficiencies, and good ideas. Everything I’ve described in this post works well for our team, but may not work for yours. You should treat your process like a product and iterate toward process-team fit.

For example, in a recent meeting about a front-end feature, one of us added a mock-up design to the meeting doc. This greatly enhanced the conversation, and someone brought that up in their feedback at the end. It led to a new rule: include a picture or mock-up whenever the decision will include design. Seems like an obvious rule in retrospect, but it took that 5 minutes of explicit reflection to recognize it was missing from our process.