Introduction
Before I launch into the body of this essay, let me say that I think meetings are wonderful things. I'll even go so far as to say that people in my field, software development, probably don't have enough meetings. I have to qualify these opinions, however, by saying that they only apply to the right kinds of meetings. Regularly scheduled project status meetings that involve an entire team are definitely the wrong kind of meeting. They provide very little useful communication, and they kill productivity. There are better ways to accomplish the purpose of status meetings without actually having them.
What's Wrong with Project Status Meetings?
A project status meeting usually involves a manager and a team. Each member of the team, in turn, provides an update on the tasks that member has been working on since the last meeting. The manager or other team members may ask for additional information or provide comments on these updates. Team members that have little or no involvement with the tasks that are being discussed just sit and listen (or sleep, or doodle, or do what I do occasionally -- write code long-hand on a pad of paper).
In a particularly malignant version of the status meeting, several teams and their managers are in a meeting with a higher-level manager, but each individual team member still reports on his tasks. On one project, I had meetings like this on a weekly basis, with upwards of 40 different people in one room. It was dreadful.
What makes these meetings so dreadful for me is that I'm only an active participant for two or three minutes. For the rest of the time (an hour and a half, or more, once a week, on my last project) I don't have any real involvement with what's being discussed. I'm a captive. I can neither provide any useful commentary on the discussion nor gain any useful insight from it. Even worse, I'm a consultant that bills on an hourly basis. I hate wasting my client's time on uselessness when I could be doing something more productive with it.
Why I Think We Do It This Way
For several reasons, holding a management position is thought of as being a few steps up the career ladder, above the lowly status of the worker bee. I happen to think this situation is unfortunate, but that will be the topic of a later essay. In any case, people currently in management are usually older than the people that they manage, and they usually learned what they know about office interaction when they were younger, or at the very least from people who are older than they are. This means that the habits that are ingrained in managers may reflect a technological state of the art that was current ten or twenty years ago, maybe more.
Before the advent of telephones, e-mail, instant messaging, and Wikis, the only way to get a timely update from several members of a team was to gather the members of the team together at a pre-arranged time and place. Fortunately, the telephone pre-dates most people currently in management, so for widely dispersed teams the conference call is in common use.
I try to take advantage of status meetings held both in-person and via conference calls by arranging my schedule so that my virtual working hours fall during the times that the status meetings are held. I dial into the meeting on my cell, using a headset so that my hands can stay on the keyboard. I listen for my name, provide my update and any comments that are relevant, and for the rest of the time I'm writing code, debugging, documenting, or testing. I'm less productive than I would be if I didn't have to split my brain between the meeting and other tasks, but at least my downtime isn't a total loss.
A Better Way
Rather than holding status meetings in person or via conference calls, why not take advantage of that wonderful new invention called e-mail? Every team I've worked on since 1993 has had e-mail. It's safe to say, in fact, that I would refuse to work on a team in which one or more members didn't have an e-mail address. E-mail has reached a comfortable level of ubiquity.
Here is what I propose: On a regular basis (for example, before noon every Monday) each team member would send an e-mail to the team's manager and copy every other member of the team. The subject of the e-mail would clearly state that it contains a weekly status update: "Status Update for 2011/01/31." The body of the e-mail would contain a suitably detailed list of that team member's assigned tasks and their status. It might also list the accomplishments of the past week and the problems that are retarding progress on current tasks.
Each team member could read these status updates at some point in the day and perhaps send a follow-up e-mail to other relevant team members to provide additional comments or ask questions. A meeting could be scheduled among interested parties if a topic needed to be discussed in more depth, or a meeting may just happen spontaneously in a phone call or around a whiteboard.
This kind of arrangement provides several advantages. First of all, it eliminates the need to synchronize everyone's schedule around an event at a particular time and place every week (or every day, if a team is particularly dysfunctional). Second, it allows a great deal of flexibility in providing status updates to the team. Some people might compose their e-mails on Friday afternoon, some on Sunday evening, and some at 11:47 on Monday morning. Whatever fits into each person's style and schedule will work.
Finally, and most importantly to me, if one is really in a flow and madly banging away at the keyboard in a productive state that I like to call "code falling out of the fingers," there's no need to stop that state of productivity to listen to someone else drone about something which has little or no connection to whatever problem that person is thinking about. Each team member can reach a comfortable stopping point and deal with writing or reading the status e-mails on his own time.
An Aside: Flow Is King
In software development, particularly, achieving and maintaining flow is crucial for productivity. I worked on a project a while back that had a project status meeting every day at 11:00 AM. This REALLY killed my flow, because I like to spend the first part of each morning taking care of busy work, and by 9:30 or 10:00 I want to be in a really deep flow that may last until 1:00 or 2:00 in the afternoon, or whenever my hunger pangs finally remind that it's time for lunch. Once, when my wife and I were engaged, she surprised me at my office while I was in this flow state. It took several seconds for me to even recognize her, and a few more seconds to be able to shift gears into human-to-human conversation. The flow state can be that deep!
If you're a manager, you want your team members to be able to achieve and maintain a state of flow. Please, try to avoid doing anything that might interrupt it.
The Right Kinds of Meetings
As I wrote earlier, not all meetings are bad. I am a big fan of meetings in which all of the participants are focused on a particular issue. The meeting need not have a published agenda; that can often be a bad sign. All that's needed is a clear statement of what the meeting needs to accomplish. For example, "We need to figure out what databases contain the data we need to gather for the migration from product ABC to product XYZ." That's a meeting that has a chance of getting something done.
Another favorite of mine is the ad-hoc meeting, where two or three people might be discussing an idea or a problem, and before long they're scribbling on a whiteboard or sitting around a computer trying out ideas.
What these kinds of meetings have in common is that all of the participants are engaged. They're working toward a common goal so that they can get work done based on the output of the meeting. Project status meetings, in my experience anyway, never meet this description.
Why Not Try It?
I don't know why, but I have yet to convince a manager that holds conventional status meetings to switch to e-mail updates instead. I'd like to hear from some managers about this idea. Why might it not work? Are there downsides that I'm just not seeing?
