Advantages and Disadvantages of Meetings for Development Teams

Meeting. Conference call. Stand up. I don’t exactly like any of those, in fact, none of them makes me happy. 🙄 Worse luck, some conferencing is essential. So, how many meetings should I squeeze in my day? Which team meeting to attend, which to ditch? What’s the hourly cap for meetings in one’s life? Let’s discuss!

I was reading a book on SAFe recently. It turns out SAFe requires just an incredible number of meetings. An average developer spends about 20-25% (!) of their time in meetings. Product owners’ life is probably a continuous, never-ending meeting. Scrum isn’t much better either.

Now, this is strongly opinionated, but I’m still saying it. Developers should spend no more than four hours a week in effective meetings. Meetings should be about 10% of the developers’ work activities, depending on the local working day norms. For management, the bar rises to 50%, some 20 hours. Me? I spend around 20% of my time in meetings and video conferencing, like, 8 hours a week.

The first rule of meeting productivity is to cut out all kinds of status meetings. Mercilessly. If you, a manager, crave to know everything that happens in your team, I’ve got some news: you don’t need to know everything. You need to consider vital problems only.

In a scrum team, status meetings are often used to identify problems. Partly, this works. But problems are often signaled behind time because of the meeting cadence. Instead of accepting this potential disadvantage of meetings, you can structure working processes so that the team can discuss (and solve) problems right away. People need to understand clearly what problems they can solve themselves and which ones require the attention of management.

Sounds complicated, huh? It’s not! The development team needs a default right to fix any issue. They should only consult the management if the solution significantly increases the development time or it isn’t clear if the solution is correct. If the team is confident and their solution fits a reasonable time limit, they should really do as they wish. Mistakes are inevitable, for sure, but managers who solve ALL problems by themselves rob people of learning opportunities.

Problem-solving meetings with more than eight people should alarm you for real. In large groups, the energy evaporates, giving space to sluggish dynamics and dominance of one participant or two. If a giant number of meeting participants is unavoidable, at least split them into small groups to discuss and then get back together to shape the best solution.

What kinds of meetings are effective for collaboration, then?

1. First of all, meetings to establish shared context. For instance, when the CEO shares a presentation of her company vision. Or when designers get together to show what they’re working on and what decisions they make. Or when newbies are explained how the organization works. Or when the team gets together to discuss a new feature, why it needs to be implemented, and how it will happen. Sharing context is crucial: without it, uniting people with more or less common goals is impossible. Without it, your company becomes a group of poorly interacting teams, and teams become groups of poorly interacting people.
2. Problem-solving meetings are another type of necessary communication. Looking for solutions on your own is loads of fun, but it’s even more exciting when you do it in small groups. For maximum productivity, make it a lively discussion with three to six people. They all need to prepare, though, and think about the solutions in advance. For some reason, this simple rule is often neglected, as if you can just join a meeting and solve problems with no run-up. Well, sometimes you can, but in terms of depth, discussions profit tremendously from individual preparation.

What about all kinds of planning sessions? They are helpful, if they establish a shared context. Are retrospectives helpful? Yes, if there are technical problems solved in them. It’s generally highly recommended to start with zero meetings and add some if needed. That’s what all those cool startups do.

Unfortunately, over time, more meetings are scheduled, and then they stay in the flow forever. As a result, older companies spend incredible amounts of time in conference rooms just because it’s always been like this, and no one wants to mess with a tradition. That’s exactly why you need to review all the existing meetings every now and then, remove ones that don’t contribute enough, and, without mercy, replace them with asynchronous communication. For that, try writing. And, sure thing, try Fibery.