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.
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.
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:
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.
Enter your details to receive our monthly newsletter, filled with incident related insights to help you in your day-to-day!
Using DORA metrics deployment frequency to measure your DevOps team's ability to deliver customer value
By using DORA's deployment frequency metric, organizations can improve customer impact and product reliablity.
Luis Gonzalez
Learning from incidents is not the goal
Learning from incidents is a hot topic within the software industry, but the goal is not for organisations to learn from incidents: it’s for them to be better, more successful businesses.
Chris Evans
Trust shouldn’t start at zero
Whenever someone new joins your team, folks tend to default to a trust level of zero. Here's why that's a big mistake.
Pete Hamilton