Bad meetings are probably my least favourite thing about the job.

Here's the common scenario I see - the product owner/BA/product manager has identified a customer need, and the designer has come up with a design for the user interaction that will solve this thing. We now need to plan and build the thing - and so what I commonly see is that a meeting will be scheduled that will consist of:

• 2-3 developers,
• a project manager,
• a product manager,
• two testers,
• the designer
• a BA.

Basically anyone who might need to have an input or be informed of the decision being made are in the meeting.

I think the reason meetings like this occur, is the thought that if someone's input is required for the meeting, then they're on hand to give it, and at the same time, those who need to be informed of the decision are their hear it in real time - efficiency - killing multiple birds in one stone. Let's book an hour so we've got plenty of time to get through it all.

This is a false efficiency.

People who are bored aren't paying attention anyway

If the meeting is only tangentially relevant to half the people in the meeting, those people are probably not paying attention anyway, so any efficiency in having them there is wiped.

This problem will be particularly acute with remote work, where people are likely browsing the internet, or trying to work on their pull request while being in the meeting.

Large meetings are not effective at soliciting input

There are a lot of reasons why someone might be more reluctant to add their input in a larger meeting.

• They're shy.

• They're worried about looking ignorant in front of their colleagues. A meeting participant may be completely lost, not knowing what an XYZ-Foo is and why one is needed, and possibly other people don't know either, but they're not about to pipe up in front of fifteen of their colleagues. And if they were to pipe up, this would be wasting the time of the colleagues who do know what an XYZ-Foo is.

• They're cognisant of people's time and attention, they don't want to waste fifteen people's time with what might be a trivial edge case (that trivial edge might be exactly the kind of input the meeting is trying to solicit!).

• They may disagree with someone in the meeting on a point, but don't want to have that disagreement in front of fourteen other people.

In my experience, you are far more likely to get candid inputs from people in small meeting.

You can get into the details and not wait to 'take this offline'

Often in these large meetings, two people will be getting into the details and the phrase 'let's take this offline' will be uttered. Fair enough, we don't want to be misusing people's time.

In a smaller meeting those details can just be gotten into.

The nature of a meeting should change with size. The smaller the meeting, the more informal it can be, and the more input can be effectively solicited. The larger a meeting, the more formally structured it should be, the more planned it should be, A large all hands with 200 people should be a rehearsed and polished experience, something akin to a conference presentation.

Smaller meetings can be shorter

A smaller meeting, with a clear agenda, can just end after ten minutes, if everything is sorted.

With a large meeting, because it's so hard to find a time that suits everyone, there's the temptation to lump multiple topics into a single meeting, getting all the items that need to be considered done in one large meeting.

Of course by the time you've got to the end of the hour, everyone is exhausted and the issues at the end are not being given the consideration they deserve.

Often there is some context that participants require to make sense of the meeting.

In a large meeting it's likely that there will be people with a range of familiarity of the matter.

Then, either you don't spend time explaining some fundamental context, and you have people who are absolutely lost, or you spend time outlining those fundamentals and are wasting the time of the other 80% of people.

How the hypothetical (series of) meetings should be run

First meeting

The BA, designer and one or two of the developers have a meeting, where the design is demonstrated and it's opportunity for the developers to interrogate edge cases in the design ('what should happen if that API request times out?').

The point of this meeting is to identify any clear holes in the design, and to act as a starting point for the developers.

The developers can also think about how the testers are going to test this thing, whether it's a straight forward thing, or whether some kind of mock workaround is required.

Second meeting

At this point the developers might get together to discuss the technical drama that they might have in building the feature.

Let's say that at this point the developers identify a flaw in the initial design - perhaps the feedback from the server can't happen synchronously, it might occur a minute or two later. The developers can come up with alternative design, a notification toast that sits in the corner of the page, and take this to the designers.

Third meeting

The devs meet back with the designer.

Maybe this ends up being a really quick 'hey, the initial design isn't going to work, how about a notification toast?', 'yes that makes sense, let me create a design for you'.

The point here is that meetings with just the relevant people in them are going to more effectively get to the point, and then you can move on to the next thing.

It sounds like I want more meetings

In a way yes.

There's a sense that what I'm proposing resembles a relay race - where the handoff from one meeting becomes the input for the other.

At some point it might make sense to then get say these three groups of participants together for a final go around, but this should be a last resort, not a first one.

One thing you could do is block out say a three hour slot in people's calendars, and tell them 'you're not going to be in meetings this whole time, but you can be available to be pulled into a meeting'.

Practical tips for better meetings

• Have an agenda.

The agenda should include a timeline of checkpoints - 'At 10 minutes, Joe should be giving a brief overview of what an XYZ-Foo is and why need one. At 15 minutes, Joe will be making the case for using the Z-Zelta technique to implement our XYZ-Foo.'

Timeline the meeting such that it aims to finish at least ten minutes before the full hour, twenty minutes would be better. This will allow some overage, without having to completely cut things short. A meeting that needs to run right up to the full hour is a badly planned meeting.

The agenda should also include the meeting goals. Is the purpose of the meeting to inform people of something? To make a decision?

• Start the meeting with the agenda.

• Stick to the timings set by the agenda, don't like a single issue derail the entire meeting.

• Adopt Jeff Bezos' meeting tip, where:

1. Meetings are required to have a prewritten memo outlining what is to be discussed or decided on.
2. Time is allocated at the start of the meeting to read the meeting memo.

This forces the meeting organiser to have done some work upfront to ensure a focused, rather than relying on the meeting participants to provide the focus.

I've found this is particularly useful for sprint planning and backlog grooming meetings, where we take the time to read the ticket quietly ourselves before any discussion is done.

• Where a meeting is a 'get input from everyone' exercise - allow the creation of input in the weeks before the meeting.

I've found this useful for sprint retrospectives. I find often by the time the retro comes around, I've forgotten the things that were bugging me, or that were working really well. It's much easier if I can add them to the collaboration board as I encounter them.

• The meeting host can invite people to drop off when they're no longer needed.

Questions? Comments? Criticisms? Get in the comments! 👇