A developer's guide to having great meetings

A developer’s guide to having great meetings

Facilitating meetings is a skill in itself and something I certainly didn’t learn in my few years of studying computer science in university. When I started my career I felt more comfortable in front of my monitor than in front of people in a meeting room but as I have had to facilitate more of these I learned how to do them better. So now in the spirit of sharing what I’ve learned over the years here are a few tips to help you have great meetings.

Let everyone know why you’re inviting them

Meetings like method names and variables are best when they explain themselves. Just like you would write a comment in code to explain things, writing down a short note in the meeting invite helps those invited to figure out why they’ve been summoned.

Like most developers I’m introverted too so just walking up to people I’m not comfortable with takes time, courage and energy. Since I’m not comfortable with everyone I send a quick message to those who might not be expecting a meeting invite just to give them a heads up and in case they forget I write it down in the meeting request like so:

Have an agenda ready

This is may sound obvious but its surprising how many people have an agenda that is simply “Lets talk about this topic”. Personally I find that open ended agenda like that aren’t the best I’d rather phrase it like this. Rephrasing from the earlier example:

Of course its not always that easy. Sometimes we call meetings to gather ideas or to get feedback. Here’s some inspiration when it comes to goals I’ve set for meetings in the past

• Come up with a decision for (some issue)
• Have a list of ideas to try regarding (topic)
• Have a list of feedback regarding (topic)
• Have action points regarding (issues)
• Get (person) informed of (topic)

Start the meeting with a goal

Think of the first minute of a meeting as the name of your function or class it should tell you exactly whats about to happen when you continue reading inside. This serves as a reminder for people and a chance for people to focus on the task at hand.

Sidebar discussions

During spirited meetings its easy for us to deep dive and try to problem solve every little issue that comes up. Remember that time when someone mentioned a bug and you started debugging in your head and asking for more and more details then the next thing you know 30 minutes has past and everyone is either in trying to figure this bug out with you or wishing they were elsewhere? I do because it has happened to me before and I know something similar has happened to you too. This is where the concept of a sidebar is well appreciated. My personal flow when getting people to sidebar is to

• Let them know that we’re straying away from the topic.
• Acknowledge that their deep dive is important but now isn’t the time for it.
• Reassure they’ll have time for that discussion.

Here’s an example:

Hey guys we’re starting to spend too much time on discussing this one security issue and we still have other things on the agenda. I know its an issue we have to address so we’ll make time for it after the agenda or we’ll set another meeting just for this okay?Give people an early out

Consider meetings to have a fail fast approach just like you’d throw an exception and stop the flow when an error happens you should also allow for people to get out of the meeting when it no longer makes sense for the people inside. For example once the agenda is done and we’re using time to tackle sidebars then its a good time for other people to go early. I like to believe that everyone would be interested in the discussion going on but if for some reason they’re not then leaving a gap for them to exit would be fine. In the example used above:

Guys thanks for the updates we’re going to start talking about whether we can push through with the release or not. If you’re interested for that discussion you’re more than welcome to stay but if you got stuff to do then you’re also free to goWrap it up with style

I like to end my meetings with something energetic. How you do that would be completely up to you but having some flair to how meetings end leave a good last impression. To finish off our example meeting earlier

So we’ve come to a decision on what to do and we did it within the one hour we allocated for this meeting. Good job guys let’s go!Post meeting feedback

Just like you’d get a peer to review your code to look for improvements, meetings work just the same way. There’s nothing stopping you from asking someone who was there what could have gone better then trying it out at your next meeting.

There you have it! There are the big things I’ve learned while going from the guy who was scared of meetings to the guy people ask to help facilitate theirs.

A developer's guide to having great meetings was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.