Running efficient meetings for engineers

During my time as a software engineer, I always hated meetings, there’s nothing more boring than going to a meeting for which it was not really necessary for me to be there, contributing nothing and just nodding along. That was a long time ago — now I view the meetings as a necessary evil and an efficient communication tool.

Over the years I’ve run lots of meetings — some of them successfully, some not so much, but I think I learned some lessons along the way. We at mindnow always have multiple projects running at the same time, so having meetings for us is important to keep the decision-making as seamless as possible.I would like to share with you some of my learnings on how to run efficient and productive meetings with your engineers. Take all of this with a grain of salt, as these are my personal observations and not necessarily best practices in the industry.

Simple Truth

Let’s start with the simple truth — to finish any software project you will probably need to conduct at least a few meetings — with clients, with developers, with product owners, etc. The question now is: why would you want to meet with them? If you just want to tell them the status of the project — an email will be just fine. If you want to gather feedback a meeting may be a possibility.

In my opinion, there are only 2 scenarios when you really need a meeting:- you need something from someone, i.e. feedback, decisions, ideas, etc.- someone else needs something from you.

Can the meeting be an email instead?

If your goal does not fall into any of the categories above, then it’s better to do an asynchronous communication via email.

Programmers prefer asynchronous communication so as not to be disturbed during their coding flow. This is completely understandable and needs to be taken into account when thinking about arranging a meeting. If there is no discussion necessary or if the discussion will be really short, it’s probably better to write a long email rather than gathering everyone for 45 minutes.

Only relevant people in the meeting

People need to have a purpose

Having someone in a meeting should have a purpose. Communicate everyone’s role in the meeting invitation to the person knows what is expected of him. I have a rule of thumb only to invite people who are part of the group that needs to make the decisions or have an influence on the decision. Everyone else will receive an email update after the meeting with the meeting protocol.

Have a moderator

This person should keep the meeting on point and redirect the flow of conversation back to the original topic if necessary. If any topics are raised that are not part of the agenda, they should be written down for future consideration. Some of those points may be discussed at a later date, this helps to ensure that some useful topics get discussed eventually and not get lost. It’s not uncommon to uncover some topics that were hidden before and schedule a meeting to discuss it so as not to derail the current agenda and maintain the structure.

Have someone to take notes

Someone needs to be the note-taker during the meeting, it’s either the same person all the time or a role that is being passed down in a circle. It’s important to write down the decision and the action items that were agreed upon. After the meeting, everyone should get a copy of the document to read through later and refresh their memory.

Preparation and structure

1–1 meetings instead of group meetings

Do you really need to invite all of the people to the meeting? A 1-on-1 meeting is more productive as there’s a dialogue happening and not just a few people talking while the rest are daydreaming. It builds a better relationship with your employees and also allows them to share ideas and concerns without feeling judged. Some people may rather introverted and not speak up during a meeting even when they have valuable input in mind.

Schedule all meetings on a single day

To avoid disturbing your developers too much it makes sense to schedule all meetings on the same day, that way they will know that Tuesday is the meeting day and will mentally prepare to discuss everything, instead of constantly being pulled out of the flow during other weekdays.

Do the preparations

The most frequent problem that I noticed afflicting meetings is vaguely defined objectives. If you’re not exactly sure what you’re trying to accomplish with the meeting, you can be sure no one else will know either. You need to do the preparations, set clear goals, clear structure, and presentation. Prepare these things ahead of time and specify exact timing for each block and moderate the flow.

The presentation/documents/other-relevant-material should be sent beforehand, no need to present it during the meeting. It makes sense to allow the people to review the documents before the meeting and think it over.

Staying on point

Summarize and repeat back what was discussed after each point

This goes hand in hand with the moderator duties. It’s crucial that everyone is on the same page and no misunderstandings occur. To avoid this, each conclusion or a decision-item needs to be repeated and see if anyone raises any objections.

Have guidelines for your meetings

Having clear behavior guidelines is critical for healthy discussion. It’s important to assume:

• No one wants to purposefully make someone look bad. Assume the aim was positive and with good intentions.
• We are all in the same boat, and everyone is equal during the meeting. You need to accept that there may be different opinions and opinions on different levels. The opinion of a junior developer will count as much as the senior developer’s. It’s important to voice concerns even if it opposes the opinion of someone else. No need to automatically agree with a senior developer when he proposes a solution or says something, he may be wrong. We need to criticize and take a hard look at each solution — this allows us to find the best possible answer.
• Ensure your ideas are clearly described so as to avoid any misunderstanding. It’s the job of the speaker to make sure the ideas are correctly interpreted.
• Be respectful and professional. No calling names or making it personal — we’re all professionals, right?

Timing

Avoid pre and post lunch meetings

Hold meetings early in the morning, or later in the afternoon to make sure that there is nothing else distracting your team. Thinking about the lunch that you’re going to eat and thinking about the lunch that you just ate is quite distracting.

Be punctual

If the meeting was scheduled for 08:00, then it starts at 08:00. Don’t wait for latecomers. Soon enough the latecomers will start coming in at the exact time as no one likes to be embarrassed by barging in during the middle of a meeting.

Final thoughts

Here at mindnow, I try not to consume more than 10–20% of the developers’ time per week with meetings. There’s literally nothing that can be discussed for more than 8 hours of meetings per week, and if there is, it can definitely be summarized into an email.

Share your thoughts on this? I’m interested in how you do meetings at your company! Drop me an email anytime.

Running efficient meetings for engineers was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.