How to run meetings that don't suck

Before becoming a software engineer, I was a consultant at Accenture. I took on a number of roles ranging from incident management to solution lead, but they all had one thing in common: meetings. Consultants live and breathe meetings, and I was fortunate enough to learn from some really talented and experienced people.

When I moved into software, I discovered that people thought I was really good at running meetings. I don’t think I’m naturally gifted at this - it’s not something I found easy in my early career - but maybe all that practice helped me develop useful techniques.

Before The Meeting

Define a clear purpose: information sharing, problem solving or decision making. This helps keep the meeting on track, as everyone knows why they’re there and what the definition of done is.

Use a pre-read document to create shared context. This doesn’t have to be an essay: a few key bullets explaining why the meeting is happening, and any background you’d expect people to understand.

There is a maximum useful number of people. For information sharing, that number might be quite high, but for a problem solving session you’ll struggle with more than 5 or 6 voices in the room.

Try to give people enough information to make an informed choice about whether to attend. Trust is important here too: if there’s not enough trust in an organisation then everyone wants to attend every meeting as they don’t trust others to represent their point of view.

Allocate enough time to cover the content you need to. If you’re short on time, use asynchronous communication (perhaps comments on a doc, or a Slack/email thread) to get more shared context. That can help give you more time in the meeting to focus on whatever needs to be face-to-face.

Remember that we are all humans. Don't squeeze important things at 5:30pm, or long meetings just before lunch. Very few people can genuinely focus on something for more than 90 minutes at a time. If you think your meeting will take longer, consider whether you can split it in two, or do some asynchronously.

During The Meeting

Choose someone to facilitate the meeting. That might be you (the person who organised the meeting), but it doesn’t have to be.

Asking someone from outside the team to facilitate the meeting can be really useful, particularly in meetings where everyone in a team wants to contribute (e.g. retrospectives). This is also useful for meetings where emotions might run high, such as a review of a high profile incident.

The facilitator should:

• Set the scene: get everyone aligned on the purpose of the meeting, and what you are asking them to do (listen, problem solve, decide).
• Make sure someone (either the facilitator or someone else) is taking notes. These notes should be at an appropriate level of detail for the meeting: some meetings warrant a full write-up (e.g. to send out to the rest of the company). Others might need a couple of notes, mainly keeping track of action items that come up along the way.
• Keep the meeting on track: try to pull people out of rabbit holes, including yourself. Keep an eye on the time. If it doesn’t look like you’re going to reach your meeting’s original goals, call that out to the group. Can you change the goals of the meeting, or maybe leave a particular decision point to be made afterwards so you can continue.
• Wrap up at the end. Make sure everyone knows what the next steps are, and any follow-ups have clear owners (and perhaps even deadlines/priorities). Any notes should be circulated, at least to the meeting attendees and possibly more widely.
• Once you’ve reached your meeting goals, end the meeting. There’s no need to keep everyone just to fill the calendar slot.

It’s important the facilitator is empowered to actually facilitate the meeting. If they’re an inexperienced person in a room full of C-suite folks, they’re going to struggle to be effective.