As a software developer, I am not the biggest fan of meetings. There are meetings where I am not necessary to be there at all and I could have been spending that time building software. It’s not that I have anything against meetings… in fact, I find meetings to be a necessary evil, but it needs to be done right (effective).
Now, this is just from my personal perspective as a software developer, so take it for a grain of salt. It is by no means meant to be best practices in the industry.
What Is an Effective Meeting?
First off, before anything else I want to make the distinction between efficient and effective meetings. A meeting that is efficient doesn’t mean it was effective. An efficient meeting starts on time, have good time management, includes as few people as possible, and achieves the stated objective. So, the job is done, right? Well, that depends on if it really generated any value for the business. If everyone coming out of the meeting have no clue what is the next step then not much value was generated.
An effective meeting is different because:
- There were tangible results such as a decision, a plan, a list of ideas to pursue, and most importantly a shared understanding of the work ahead
- The right people were involved
- Results are shared with others whose work will be affected
Clear Purpose
An effective meeting needs to have a clear purpose. A big-time waste is recurring meetings that no longer bring value to the attendees and or the business. A trap that is easy to fall into is viewing meetings as the only way to collaborate when there are so many alternatives out there.
Determine If a Meeting Is Necessary
There are definitely occasions, where a meeting makes sense while others are not. For example, a meeting shouldn’t be held just to share information. You have chats, email, Confluence, etc for that.
Situations where a real-time discussion will be more effective than emails or chat should probably be a meeting. For example, team or project retrospectives, brainstorming, high-level whiteboarding of solutions, 1-on-1 meetings between managers and their direct reports.
Invite the Right People
The people involved in the meeting needs to have a purpose. In the meeting invitation communicate each participant’s role so they know what is expected from them. So, in most cases, the people that should be invited are part of the group that needs to make the decisions or have an influence on the decisions. Send an email update to everyone else about the results of the meeting.
Have a Moderator
Every meeting needs a moderator even if they never need to carry out their role. The moderator keeps the meeting on point and redirects the flow of conversation back to the original topic if necessary. Any topics raised that is outside of the agenda should be noted for future consideration. It is perfectly fine to uncover some hidden topics during a meeting and scheduling a separate meeting to go over them. Just make sure to keep those out of the current meeting because that’s what everyone else is there for.
Have a Note Taker
It is important to write down the decisions and action items that resulted from a meeting. A meeting should have a dedicated note taker that documents the decisions and action items. Once the meeting is over, everyone part of the meeting should receive a copy of the document so they can reference it later. If you think a week or two from the meeting everyone will still remember all that happened in a meeting you’re in for a big disappointment.
Schedule Meetings on the Same Day
Software developers work in blocks of time (builder mindset). So to disturb them the least, you should schedule all meetings on the same day if it makes sense. That way, developers will know a certain day is a meetings day and be prepared for discussion. Constantly pulling developers out of flow is not a great way to be on their good side. Also, if a developer knows a meeting is coming up they won’t be working because they know it’s not enough time for them to get into flow.
Do the Preparations
Having an agenda is important to help the participants know what will go on in a meeting. However, the meeting also needs to have a clear objective. If you or the one who initiated the meeting is not sure what the meeting is trying to accomplish, you can be certain that no one else will either.
As the initiator of a meeting, you need to set clear goals, clear structure, and presentation. Any presentation(s), documentation(s), and other materials should be sent out to the participant in advanced. Otherwise, you’ll distract the participants when you bring up those materials and they will not pay attention to you. In addition, by providing documentation beforehand, it allows people to have time to review them and think them over.
Be Inclusive
Some developers are on the more introverted side. So, they’re not going to jump into an ongoing discussion often. If you notice that try to include them by asking them towards the end of the discussion if they see points the group may have missed. Just to be clear, this isn’t meant to put someone on the spotlight, so make sure to frame the question asking if they have anything to add and not demand input.
Focus on the Results
If the meeting centers on a decision being made, don’t let everyone in the meeting off the hook with a “maybe”. A “maybe” really means no action will happen after the meeting, which means the meeting was a waste of time. Push for decision or at least a recommendation so people can take action after the meeting.
Avoid Pre and Post Lunch Meetings
Meetings before lunchtime or right after lunchtime are just very distracting. Before lunch, you’re thinking about what to have for lunch and after lunch, you’re thinking about the food you just ate. It’s difficult to focus in either case, so it’s better to just not have meetings during those times.
Continuous Improvement
No one is perfect and you shouldn’t expect to run perfect meetings either. Having a perfect meeting is the overreaching goal that will not happen in the majority of cases. However, that doesn’t mean you can’t get feedback and improve on the weak points in meetings.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What are your experiences with meetings? How does your team utilize meetings?
To stay in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.