Why I’m not in favor of in-person or voice status meetings
So, one of the things I occasionally have to put up with in my day job is status meetings. Fortunately, I don’t get sucked into too many of them, and also fortunately, I get paid by the hour. However, recently a volunteer project that I’m coding for attempted to institute regularly scheduled status meetings. I tried two, and then announced my disinterest in participating in any further ones, but I thought I might take a minute to explain why I think these types of meetings are counterproductive and better handled over a text asynchronous channel.
So, a list of the reasons I don’t think they’re the right venue:
1) Voice is not seekable. This means that you can’t ‘fast-forward’ over parts of the meeting that are not relevant to you – and in the case of this particular project, we’ve got two developers (me and A) working on two separate codebases that only touch via a defined API, so by definition anything that isn’t my description of my status isn’t relevant to me. This also means you can’t ‘rewind’ to hear something you missed – and if you’re listening to a bunch of people talk about things that are mostly irrelevant to you, you’re therefore forced to still give your entire conscious experience to listening so that you don’t miss a irretrievable chunk of audio that *is* relevant to you. With text, you can easily skim or skip ahead or look back to any bits you missed
2) Voice is expensive to decode. This is easy to demonstrate by looking at how much CPU it takes us to do even flawed voice recognition. Our minds have a lot of computing capacity, so we generally don’t think about this, but it takes a lot more mental CPU to decode voice than it does to decode text. In my case, reading a incoming text while coding often does not require a full ‘context switch’, while listening to a incoming audio/voice message does. Neural context switches are expensive – they mean wasted time and lost momentum.
3) Voice is fast to send, but slow to receive. I don’t know about the rest of you, but I can talk slightly faster than I can type, but read many times faster than I type. This means that a group getting status updates via voice is wasting whatever overspeed beyond hearing their reading speed is times the number of participants in the group.
4) Scheduled meetings are to be avoided whenever possible as they present a spinlock that blocks all CPUs / are a forced synchronous event. I don’t deny that there are appropriate times to have a meeting. A decision which requires group consensus, a blocker which everyone on the group may have input that can help resolve, and a celebration of a accomplished task (major milestone) are all examples of meetings that I would think of as being a good idea to hold. However, let us not lose sight of the fact that meetings are *expensive*. They cost the time of every person in the room, plus the time to set up the meeting and agree on a scheduled time – something that presents a extra challenge in my case because I do not adhere to any type of standard sleep schedule. And status meetings do not, generally, move the ball down the field.
5) Having a scheduled meeting to discuss blockers encourages a counterproductive behavior. If you get hung up on a blocker, the best first step is to see if anyone is available to help you with it, *right now*, and to do research using google and the like to see if a solution is already out there. Beyond that, the next logical step is to document the blocker in a asynchronous communication channel like email or skype and ask the people who can potentially resolve it for help, allowing them to respond in their next available time slice. Having a scheduled time each day or week to discuss blockers discourages treating them as something to be resolved as a interrupt. If your project is experiencing enough blockers that the majority of team members have one to present at a scheduled status meeting, you have other, bigger problems that you should be spending your time resolving. You may have a lack of appropriate documentation or massive technical debt, or very poor communication methodologies.
6) Neural context switches are expensive. I touched on this in #2, but let me amplify my thoughts a little bit. Most of us can only keep a few threads visible in our conscious experience at any point in time. In order to participate meaningfully in a group meeting, we generally have to drop the context of what we’re currently working on. This means that we have to push whatever our current state is into medium-term memory, and then pull it back out at the end of the meeting. This takes considerable time and also breaks up the energy and momentum of whatever we’re currently doing.
7) Hitting exact scheduled times requires some buffer time – whenever you have a scheduled meeting with several participants, you do NOT want to be late, because that’s causing dead time for everyone else participating, but thanks to the realities of modern life, the only way to not be late is to plan to be somewhat early, in case something goes wrong. This is part of what makes meetings expensive, and why they should only be used for purposes that require them.
8) Voice has considerable switching deadtime – handing the baton / token between participants in a voice meeting often involves many seconds or minutes. This is especially a problem over the phone – in person we generally have body language that resolves who should talk next fairly quickly.
In general, as I’m on record as saying, whenever possible, I prefer using a text broadcast medium for status updates (i.e. “I finished this”) and one-on-ones for resolving technical difficulties. I participate in meetings regularly – including some ill advised ones – but you only get to drag me into ones that I think are counterproductive if you’re paying me.
Now, the person who suggested the meeting said one of the reasons it was important was “he didn’t even know what I was working on.”. This is healthy and normal. In general, as long as I’m completing my queue, the only person who needs or should want to know what I’m working on is me. It’s a waste of mental horsepower for more than one person to be keeping track of something that one person can do. I make exceptions for mission critical ops (things like SSL renewal, or race car prep, or whatever) where one person dropping the ball can put people or the project in actual danger. But normally, wanting to know the exact details of something another team member is doing is a sign of micromanagement, which is a very bad idea.