If you’re a Software Developer, I’d bet you like coding and that you’d rather ship that feature you’re working on than attend yet another meeting. Even worse if you have no clue why you were invited to that meeting in the first place.

There are too many things to say about meetings, and sadly I cannot cover all of them in this article, so I will focus on concrete examples of meetings that I have seen working in real life, and counterexamples as well.

As an introduction, I will cover what makes a meeting effective and I will offer some tips to make meetings effective. Then, I will discuss some guidelines to decide when a team should have a meeting, to finally give some advice on how you can empower your team so meetings play in its favour.

Effective meetings

Meetings are a valuable mechanism to collaborate with others when used appropriately. However, if misused, they can impact the productivity of teams involved in them.

Once, I worked on a multi-team project led by a very experienced engineer and closely monitored by an even more experienced engineer. We were invited to daily one-hour meetings whose main goal was to discuss the future of the platform or talk about high-level topics that had no impact on our work. It was really funny that the meetings were called “daily standup,” but I was never asked about my work. This is an example of a meeting that wasted many people’s time.

To illustrate my point even further, there were no meetings between the teams to coordinate their work and address the low-level challenges that we were facing. I even recall speaking to a lead engineer that was unaware that another team had a dependency on their work. This is an example of a recurrent meeting that would have been extremely useful, but never happened.

What these examples show is meetings can have a concrete real impact on your project (if you’re curious, this project was not delivered on time, and what was delivered was well below the company quality standards). This is why running the right meetings is so important.

Tips

In my opinion, the following are the most important points to consider if you want to have a successful meeting:

• Check if you need a meeting, and check if you really need a meeting.
• Invite people who really must be there.
• Prepare an agenda: What is the desired outcome?
• Encourage participation.
• Record all decisions.
• Record next actions, due dates, and assignees.

If you would like to learn more about these points, I would recommend this article by Atlassian on the topic: https://www.atlassian.com/blog/teamwork/how-to-run-effective-meetings

One size doesn’t fit all

Before Covid, when everyone was at an office, meetings were not as critical as they are today. Interactions between team members would happen naturally as needed, and it was more or less clear when a meeting was needed or not.

If your team follows Scrum, then you may be accustomed to Daily Scrum meetings (a.k.a. Standup meetings).

When I started working remotely during Covid, my team continued having the same ceremonies that we were used to. Soon, we realized that it was not enough. The team needed a space to ask questions or simply talk to another soul. Our solution was to add a “second standup meeting” in the middle of the day. This measure had a clear positive impact on team morale, and I am inclined to believe that there was a productivity boost, although I don’t have any numbers to support this claim.

Interestingly, I’ve encountered only one other team in which this strategy made sense, and the team was thankful that we did it. A developer doing a secondment on my team was eager to introduce the practice to their original team. This was my advise:

A practice that works for one team does not necessarily work for another. If you think that this practice makes sense for your team, don’t be afraid of proposing it. However, don’t take it personally if the idea is declined: the team may not be ready for this idea, or may not have the problems that make the solution worth it now.

The same happens with other meetings, like the Backlog Refinement. Every team does it in a slightly different way. Some teams have a Backlog Refinement meeting, others do it asynchronously, and in other cases, the engineering lead refines the Backlog by themselves.

I have observed that engineers tend to avoid Backlog Refinement meetings whenever possible. One reason I’ve heard is that it usually takes a lot of time. Another is that in Multi-Disciplinary Teams, developers don’t have enough context or relevant thoughts on what others do, and so they think that this is a waste of time. It is easy to disregard these comments, but if you feel this way or are aware of this situation, I would encourage you to speak up.

One easy way out is to just ditch long meetings. However, if there is any value in having them, I would suggest that you keep the valuable part and remove everything that doesn’t need to be done in a meeting. In the case of backlog refinement, something that I’ve seen work in some teams is that the team or project lead refines the backlog; then the rest of the team reviews it in their own time, at their own speed; and finally, the team meets for a few minutes to discuss anything that may be unclear or do further refinement.

Meetings that involve multiple teams or an entire group are trickier. Large groups have different needs, and it’s virtually impossible to make everyone happy. That said, it’s always worth trying. I once worked on a team that ran fortnightly demo meetings, and the group we belonged to had weekly demo meetings. In practice, every fortnight, we had two demo meetings with the same content. I proposed that the group meeting be run every two weeks, and the ideas was not approved. But hey, I tried 🙂

I do not intend to go though every meeting or type or meeting I’ve ever been. These meetings are so frequent nowadays that they work as good examples to show that something that works for a team doesn’t necessarily work for another.

Team Health

Irrespective of who you are in your team, if you have been there long enough, you should have an understanding of the team dynamics and be able to come up with ways to improve how the team works.

The only meeting that I would strongly advise to most development teams is the Scrum Retrospective meeting, even if you don’t follow Scrum. Unless you have a good substitute in place, this is a good opportunity to listen to everyone’s opinion on how the team is doing, or to say what you really think about pressing matters.

Aside from that, every team is different, so only people working in a team can really know what its pain points are. Your team may need to meet more or less than another team, and that is fine. What matters most is:

• The team’s health
• The team’s productivity

No matter how much you try, a team cannot be productive in the long term if the team is not healthy. Does your team need more people time? Does your team need more solo time? Only your team can answer these questions.

But the job is not done there. Your team will change. People leave and join, and people change, along with their needs. Maybe what was good for the team a year ago is not the best now. Doing regular checks on how often your team meets will ensure that everyone’s needs are accounted for.

The Magic Recipe

If you were expecting a magic recipe that you could use in your team, I am sorry to disappoint, but I don’t have one. Meetings are all about people, and so they can vary as much as the people in them.

However, that is precisely why its important to have them right. They don’t only have the ability to impact projects, they also impact people. By finding the right balance you have the power to get the best of people working around you.