On Meeting Efficiency

I think everybody agrees that there are too many meetings in software projects these days. Holger Schill recently wrote about this, and prompted my own post here. He basically suggests to just not go to meetings that aren't essential for you. That's a good idea. But there's more to reducing the meeting load in an organisation. Here are some thoughts.

One of the main problems with meetings is that they are often badly run. So it's not just that there are too many or that some meetings are inappropriate. Those that exist for a good reason are inefficient, they waste people's time. And because they are so badly run, there need to be more meetings later, making the problem worse. There are lots of things you can do to improve the situation, all of them are well known. And all of then are rarely done:

• Clearly define the purpose of the meeting: is it for information, data collection or to make a decision? What specifically is that decision?
• Make sure you all stick to the topic at hand, for example by putting unrelated topics onto the proverbial parking lot for later.
• Ensure that whatever is discussed is concluded in a meaningful way, ideally with a decision or clearly defined follow-on tasks.
• Capture decisions, results and open issues that should be covered separately, potentially in a smaller meeting with only a subgroup that then reports back.
• Uncover attempts at mis-steering the discussion by putting up straw men and unrealistic, simplified or generalised statements about the issue at hand.
• Detect and shut down activities of ‘sabotaging‘ the meeting for reasons of ego or company politics. Or when people talk just because they want to hear themselves speak or to demonstrate competency (and don’t contribute to the substance of the meeting).

Another issue is that there are generally too many (non-contributing) people in meetings (which is where Holger's "just don't go" strategy helps). One reason for that is related to the notion of a clear purpose: if the meeting's topic is weakly defined, everybody "needs" to join. So a clearer purpose allows for more targeted invitees.

The next issue is that in many organisations, responsibilities are diluted. Nobody is responsible for anything, everybody must be involved in all decision. Taking every decision "as a team" is not necessarily a bad thing. But it leads to more meetings, obviously. So trying to concentrate responsibilities more might help reduce meetings. By the way: if one person is responsible and makes the decisions but doesn't have a clue about the topic, that's even worse than too many meetings ...

There are also some meetings that are just useless. In many cases they are related to process ceremony. In one of my recent projects I attended a couple of Scrum refinement meetings where we repeatedly just stepped through issues and didn't do much about them at all, certainly no actual refinement was going on. But we had to do the meeting. Scrum says we have to. Maybe such meetings can be avoided completely.

Many meetings are intended for presenting work results. While sometimes such meetings serve a useful social purpose (eg., a quarterly big status presentation to sell and celebrate the success of a project to the whole org), many intermediate results can just as easily be presented via short, prerecorded videos. You create a "project feature demo" Slack channel where such videos are uploaded, and questions can be asked in a thread under the video. Only if real hard questions come up related to the feature, will we set up a meeting.

A quick anecdote: I have used this video-based approach in all of my projects over the last couple of years. In all projects I received really good feedback, people really appreciated them. Nobody else in any of these projects replicated the idea. And of course, none of the projects made it part of the process. That puzzles me.

Let's move on to meetings that are intended to make a decision. In my experience, it is very rare that such meetings are prepared adequately. The problem isn't justified as being relevant, the alternatives and their tradeoffs aren't clear, the data to evaluate the tradeoffs is unknown,the downstream effects aren't outlined, possible consequences for the business aren't stated, the affected stakeholders aren't in the meeting, and so on. As a consequence, the meeting is a half-informed, often circular and undirected conversation.

A better preparation can go a long way. Amazon has this six pager that is required prep by the stakeholder who wants the decision to be taken. I like that. More generally, decision meetings should only happen if they questions I mention above are all answered, at least to a reasonable extent. It is also not forbidden to talk to selected stakeholders in advance of the big meeting to help answer some of these questions.

Writing a six-pager (or something equivalent) requires more work for the primary stakeholder, but it obviously saves (meeting) time for all the others. A good tradeoff. However, it only works if meeting attendees take some time to prepare. They have to read and think about the prepared document. How often have you tried to make meetings attendees prepare by reading (and thinking!) about something, and half of the group "didn't have the time, sorry". So the whole prep is repeated in the meeting. That's not helpful. So a cultural change is needed that "forces" people to prepare by reading and thinking about the prep document.

Of course reading a badly-written prep document isn't fun and also usually not useful. So this approach requires a degree of writing skills for those who write these documents. Improving writing skills should be required training for every software developer! And it requires that the authors put a little bit of love into the document. Readers can small a lack of love from miles away -- the amount of thinking and feedback is directly proportional. I wrote a bit about how to write technical documents at the end of Chapter 4 in my How to Understand Almost Anything book.

A bit more attention to writing is also usually a good way of making issues (user stories, features, tasks) more useful. How often have I seen issues with just the heading. Faithful to the religion, it starts with "As an XYZ I want to...", but then the substance is empty. At best such issues are useful as reminders to those who wrote them. No wonder the refinement meetings are tedious.

While we are happily bashing meetings, it is probably also a good idea to distinguish meetings from collaborative work. A pair programming session with your buddy isn't a meeting. Neither is a series of ongoing workshops between, say, three people and changing guests to understand a domain. That's just working as a group. Should be a small group of course, and many of the practices for good meetings also apply. But there are kinds of work that you really shouldn't do alone.

So, summing up, there is quite a bit organisations can do to make meetings more effective, and, as a corollary, reduce meeting time. But again, these things aren't new and they still happen rarely. I guess then the anarchic approach of Holger is the solution: just don't go :-)