The Grumpy Developer's Guide to Meetings

Posted on 2020-04-21

While everyone is writing about remote meetings these days, I do not believe that successful remote meetings are actually meaningfully different from successful in-person meetings. I'm glossing over videoconferencing because I don't believe it is a meaningful hurdle to clear.

Like many other developers, I loathe meetings, especially when they seem like a waste of valuable time. My philosophy is "if you have to set up a meeting, at least do it right". Consequently, here are some rules for successful meetings, both remote and in-person:

The Best Meeting Is No Meeting

It is important to understand the tradeoffs involved when deciding to schedule a meeting. Meetings are synchronous discussions, which makes them useful for knowledge exchanges and decision making processes, but they are also time-intensive and disruptive for everyone involved.

The alternative to organising a meeting is an asynchronous conversation, for example on a shared document. I find that doing all the same work as for a meeting on a shared document, but just leaving out the actual meeting, is a very effective way of using asynchronous process. This can be faster than a meeting overall, as it allows participants to participate in their own time, instead of trying to find a slot that fits everyone. In addition to that, it is much less disruptive compared scheduling a meeting, especially for knowledge workers.

The only good reason for a synchronous meeting is making decisions requiring knowledge exchange and/or consensus. A good example would be planning a complicated feature, or cleaning up a backlog.

The Most Important Work Happens Before the Meeting

Every meeting needs an organiser. The organiser needs to define the expected outcome of the meeting, as well as gather all required information, and share all of these in the meeting agenda. The outcome should be tangible, like a decision or a set of tasks to be done.

The agenda is crucial, because the participants will likely have to do some preparation in advance to the meeting. If any specific work needs to be done before the meeting, like research or data retrieval, make sure to clearly assign tasks.

I recommend writing out the full agenda before scheduling the meeting, and then sharing the agenda with the calendar invitation. This allows everyone to schedule their preparation in their own time.

The Actual Meeting

During the meeting it is important to keep notes, usually in a shared document. You can designate a scribe, or just agree to all contribute some bullet points whenever possible. Both approaches have pros and cons. A dedicated scribe leads to more detailed and coherent notes, but requires a person who will not be able to take part in the conversation, at least not effectively. You want to write down any conclusions reached, important points made, and further questions and future work to be done. Do not care too much about form, the meeting organiser should rewrite the notes after the meeting anyway.

The meeting is prime talking time, and you should treat it as such. Do not spend time watching someone carry out a task. There is really no point in everyone watching a single person manipulate a JIRA board during a meeting. If you find during the meeting that you require more information, write this down as a future task instead of derailing the meeting.

The organiser should always work towards the defined outcome, but it often happens that some other discussion emerges as a precondition to reaching the outcome. There is a balance to be struck between discussion necessary to get to a meaningful outcome and veering too far off-topic.

Keep in mind that the time slot scheduled is more a rough guideline than a rule. If you can finish early, do so. If you need more time, and everyone involved has more time, take it. Though maybe take a 5 minute break. Do not try to force an outcome if you did not get there in time. If you find at the start of the meeting that some necessary precondition has not been met do not be afraid to reschedule or cancel altogether.

The Alternative: The Ad Hoc Huddle

The rules above do not mean that you cannot talk to one another without ritual. Especially for small discussions between 2-4 people, ad hoc huddles can be useful.

As a rule of thumb, these should usually be happening within the next 24 hours, so usually "later today" or "tomorrow morning".

You still need to define a goal, and you will want to write down any outcomes in some form, even if less formal than meeting notes. Even a Slack message with some findings in a relevant channel counts.