Audio version of this article

Audio version of this article

What problems are we trying to solve?

If you ever had to manage engineers, I bet you've encountered at least one instance where they vented about having "too many meetings", or made remarks such as "this meeting could have been an email", right?

There is surprisingly a lot to unpack under these statements, and through time and experience, I've come to identify several causes that can lead to this aversion towards "meetings”:

• No clear intent: Are we having this meeting to align our perspectives, make a decision, or brainstorm? If this gathering doesn't fall into one of these categories, it's likely that it could have fit under the infamous tag of a "meeting that could have been an email".
• Overloaded agenda: While meeting is necessary at times, cramming too many items into one long session may not be effective. It could be more productive to break it into two shorter sessions, spread a day or two apart, allowing people time to digest and contemplate the discussions.
• Overcrowded meeting: There can be an irrational fear of leaving people out, prompting an overload of attendees. From experience, I actually see the opposite happening: Many are relieved to skip these meetings, provided they have an opportunity to contribute their inputs and review the outcomes. Think about it: 10 people in a 2-hour meeting ⇒ net loss of around 20 hours if the meeting is not productive, or roughly three (3!) workdays for a single IC.
• Insufficient preparation: As mentioned earlier, time is precious. It's vital for participants to come prepared to meetings, allowing focus on key discussions.
• No clear documentation of the discussion: It’s crucial to document what is discussed during a meeting (consider using AI tool, like Krisp.ai, for this!). Why? Because this way, anyone who missed the meeting can quickly catch up and get back in context.
• Dev work disruption: Organising a meeting means effectively pulling people away from their work. As a leader who frequently works with developers, this is especially true for me. Therefore, I always ensure this meeting is placed at an adequate time and runs efficiently (i.e. make sure the meeting doesn't overrun, guide the conversations in the right direction, and delegate note-taking if I am not doing it myself).
• Meetings overrun: Quite often, this is the visible result of one or more issues mentioned above. It could be due to poor preparation, a need for splitting the meeting, or someone monopolising the conversation.
• Lack of follow-through: Sadly, it's all too common. The meeting ends, everyone's satisfied because they've had their say, but then nothing changes because no concrete actions were decided upon or taken! Change that!

So what’s the solution?