Skip to main content
  1. Books/
  2. Technicat on Software/

Minimizing Meetings

books management software meeting
Phil Chu
Phil Chu
Making software since the 80s

What have here is a failure to communicate.

Avoid These Meetings #

I’ll take a strong stand on meetings right off the bat — meetings are evil, and not even a necessary evil. In my first job out of college, the weekly meetings were painful experiences, filled with senior blowhards taking credit for work done by junior staff. After travelling on business one week, I enjoyed skipping the meeting so much I just stopped attending (shades of Office Space!). Apparently I didn’t miss anything, I got more work done, and no one bothered me about it.

Most of my subsequent workplaces weren’t nearly as dysfunctional, but still the meetings weren’t much more useful. Automatic, repetitive, pointless — the worst ones are the typical ones:

The Weekly #

A regular weekly group meeting is a traditional part of work life, like the coffee break. But the hours add up — say you just have one weekly departmental meeting involving forty people — that’s costing you one person on the payroll. And do you really need to herd everyone into a room to get them to communicate? To share body odors and a group nap, yes, but after all, they are supposed to be working and communicating with each other during the rest of the week.

The most ridiculous weekly meeting I’ve witnessed (and there’s heavy competition) was held by a manager who had just one person in his group besides himself. And they shared an office. Every Friday at 9am, the manager would turn around in his swivel chair and say to his officemate, “Ready for our meeting?”

Sometimes meetings are held just to remind everyone who’s the boss. If that’s what it takes, you’ve got other problems.

The Standup #

I’m not a fan of scrum. And I don’t mean rugby. The thing I hate about the variant of Agile Development called Scrum is its defining characteristic, the daily standup meeting.

The daily standup is a reaction to the traditional weekly meeting, but it’s no better. Rather than waste an hour of everyone’s time once a week, it takes ten minutes of everyone’s time every day. Factor in the context-switch time of breaking off work and then returning to work, it’s not a real time-saver.

The daily meetings are also a ritualization of the what-are-you-doing-right-now school of management, which is not exactly goal-oriented. It’s irritating enough to have a manager go around a table once a week and ask “what are you working on?” but to go through that every day is like being in kindergarten. And when I did sit (stand) through such daily meetings, I still had middle management come by later in the day to ask “what are you working on?” (I always wanted to ask them the same question)

The Pep Rally #

I am forever grateful to the high school math teacher who let us spirit-impaired nerds hide out in the computer lab during pep rallies. They were a welcome break from class, but the fact that hip-waggling cheerleaders stirring up support for our football team (despite its two consecutive years of losses) warranted time taken out of our studies gives some indication why this country isn’t preeminent in primary education.

Rah-rah corporate meetings also provide a break from work, minus the cheerleaders. They’re really an opportunity for the CEO to flex his CEO muscles — an exercise in power management. Sometimes the hypnosis works and employees fall under the sway of the exalted leader, and sometimes they just find the guy annoying, but I’ve never seen employees come away actually more encouraged and determined to work harder.

The Come to Jesus Meeting #

I’ve heard these referred to as “come to Jesus” meetings, but I think of them as panic meetings, where management realizes, belatedly, that things are not as they should be, and calls an all-hands meeting to tell everyone to shape up. I’ve never seen anyone come out of these meetings energized to work. Usually, they go off to polish their resumes.

The Group Hug #

At one point during my first job (the worst jobs have the best stories), a self-appointed morale coordinator who apparently had nothing better to do first issued Briggs-Meyer tests (we just handed the forms to our friends so we all got the presonality profiles we wanted), and then when team unity failed to result, set up an off-site two-day team-building session, down the street from our office. We held hands, took turns “confessing” how we could have done a better job (mostly phrased as “I could have done a better job in helping that guy do his job”, except for the fundamentalist Baptist who refused to confess because he wasn’t Catholic).

Here’s an idea for a team-building exercise: finish the project.

A Few Good Meetings #

Despite my allergic reaction to meetings, I do believe a few can be useful, and they may be appreciated more for their rarity.

The Kickoff #

The first useful team meeting is the project kickoff meeting. It’s important to make sure everyone is on the same page from the very beginning.

On my first project where I was a lead, I thought the project goals were pretty clear. But after a few months, the team members actually requested a meeting. After that, no one asked for another meeting, so either it was satisfactory or totally useless, but I do wish I held that meeting at the beginning.

The Countdown #

There is one part of a project where I do think it’s important to for everyone to get together and know exactly what’s going on — that’s the final days before a project release. The code should be frozen and undergoing extensive testing at this point — every day there should be a meeting to go over the latest test results and decide what to do about them.

The Postmortem #

Memories fade quickly, so start off the new project cycle with a meeting to discuss lessons learned. And anyone who feels abused by the past project is likely to be annoyed enough to honestly air their views.

However, even meeting-happy managers I’ve worked for have been reluctant to hold postmortem meetings, ostensibly to avoid finger-pointing (probably at themselves), but I suspect also because the point of a postmortem meeting is to take a hard, realistic look at the process and make any necessary changes. And no one wants to do that.

I did participate on one video game project that held a few postmortem meetings after milestone deliveries, and the sessions were useful in refining our process. Too bad all that got thrown out the window at crunch time.

Use Technology #

Technology has changed how we do nearly everything — entertainment, travel, shopping, managing our finances. So why should we hold meetings the same old way like cavemen grouped around a fire? Some technologies, like videoconferencing, just make it easier to have more meetings, much as some technologies create more paper instead of advancing us toward the paperless office. But technologies that we use to streamline the rest of our lives, standard stuff like email and web browsing, can minimize the number and duration of meetings.

Status Reports #

The most important email everyone can issue is the the weekly email report. Rather than wait for a meeting to go around and ask everyone for a status report (the most painfully boring type of meeting), the reports instead can be composed and emailed by each member of the team before the meeting — ideally, the day before the meeting. Then everyone can put some time and thought into the report, instead of dredging it up on the fly in the meeting, and everyone can spend some time digesting the reports before the meeting and consider issues to bring up at the meeting.

In all cases where I’ve seen the weekly email report initiated, the time spent in the weekly meeting easily halved, and the content of the meeting was more focused. Moreover, email reports serve as written records that can be easily referenced, instead of “I’m sure I mentioned this at the meeting two weeks ago….”

Whether or not the weekly report happens before the meeting or during, the content should not be “what I did this week”. (I had one coworker recount his trip to the dentist, and that was one of his more productive weeks) It’s a “status” report, not a “what have you been doing” report. If you’re more concerned about how people are spending every minute than what actually gets done, then you’re better off installing monitoring software at every workstation. Asking people what they’ve been doing sends a message that you care more about looking busy than what’s actually getting done.

The report should contain information that is actually useful and gives everyone else on the team a feeling that they know what’s going on. And, to put it crassly, it’s also a CYA device for developers who feel their contributions and concerns may be glossed over by their managers. (To put it less crassly, think of it as an implementation of the open-door policy that companies like to brag about) The reports should include:

Changes made to the system that everyone else should see. (For source code, these are changes committed to the source code repository and can be verified by others, not in-progress code that is on the developer’s machine).

Dependencies that the developer is waiting on — hardware, test cases from QA, code from other developers, decisions from management.

Problems that require attention — current approach is not working out, the developer is overloaded, progress is slow and target date will not be reached without more resources or trimmed features.

Everyone should issue a weekly report, not just the programmers. There are a lot of tools for monitoring software development — keeping track of marketing, sales and management activity is another matter. If every department is made more “transparent”, that can counter the typical perception from engineers that everyone else is on a coffee break while they’re under the gun. And if it turns out some people don’t have anything to report (or are reporting the same thing for weeks on end) then now you know you’ve got a situation.

The Intranet #

All project information should be accessible on a local intranet server. These days, it’s not uncommon to find a wiki set up on the intranet — this makes it easy for project members to add and correct project information. And then there’s no excuse for anyone to not understand what’s going on in the project.

Bad Technology #

On the other hand, say no to instant messaging and any other form of communication that facilitates interruption. Whereas use of email promotes thought and clarity in expression and response, instant messaging caters to the short attention span. I had one manager who couldn’t stop reading and writing her IM even while I was standing next to her giving a status report. Great example for the staff!

Some managers don’t like their employees wasting time instant messaging with the outside world, but internal IM is even more damaging — coworkers and managers will get in the bad habit of expecting instant responses to off-the-cuff questions, instead of well thought out answers to valid questions.

Stay Focused #

Have an Agenda #

It’s easier to get decisions made in a meeting if you plan the meeting that way. There are few events more uninteresting than going around the room asking for each individual to give a report. Once you get rid of the round-the-table what-have-you-done routine, then it becomes clearer that you should have an agenda (and if you can’t think of one, then there’s no point in having the meeting).

Certainly, a standard part of the weekly meeting agenda should be to address any concerns that have been raised in the weekly reports.

Release the Hostages #

Now that you have an agenda for your meeting, stick to it. This doesn’t mean slavish devotion to a list or formula — just remember why you’re there.

Some people take advantage of having a captive audience in meetings. One company president would regale us with a review of last weekend’s movie she saw or game she played, or relate some formative event in her life. Another producer would spend the beginning of the meeting telling bawdy stories and insulting the French, then snap at everyone else to stay focussed. Remember, it’s not a social gathering. Save the fraternizing for happy hour.

Start on Time #

The first aspect of a meeting is, obviously, starting the meeting. Adhering to a strict start time sets the right tone — get going, get to the high points, and get this meeting over with so we can get back to work. On the other hand, inconsistent start times not only waste time as people sit around waiting for the meeting to start, it sends a subtle message that time is not valuable, or that some people’s time is not as valuable as others.

I had one manager who would repeatedly postpone a meeting to attend to various things, and then she would complain about how she had to round up everyone for the meeting when it actually took place. Not only was this was just annoying, but it meant no one could effectively plan their work around the meeting — you would either get interrupted right in the middle of trying to figure something out or you’d be twiddling your thumbs waiting for the damned thing to happen. Not a good way to promote time management discipline in a project that was already challenged with a tough schedule.

End on Time #

The reasons for starting meetings on time also apply to ending them on time.

The best regular meetings I ever attended were held by an MIT professor for his research group who always ended his weekly meetings on time. Even if there were more items that could have been discussed, the professor still adjourned the meeting and we tabled the discussion for next time. I left that meeting never feeling that it dragged on, and on at least a few occasions I felt it was productive and worth the time!

Ending early is OK, but letting a meeting go over the prearranged time is the same as allowing a schedule overrun. If you can’t keep a meeting on schedule, what hope is there for keeping the project on schedule?

Write it Down #

Have you been to meetings that seemed like the movie Groundhog Day? Same day of the week, same time, same topics, only it feels like you’re the only one who remembers going through all of this before. (“Vampire topics” that repeatedly come back to life, as one of my friends termed them) Or perhaps you’re one of the blissfully bringing up the same topic again and again.

I participated in a two-day annual sales meeting for a startup company where supposedly we discussed our product plans and marketing strategies. You’d think in a startup with one product and only a handful of sales and marketing folks, someone would remember whatever was decided at that meeting, but I found myself repeating peevishly for months, “We discussed this at the meeting!”.

There’s not much point to a meeting where decisions made are not remembered. So make sure everything of note in the meeting is written down and distributed to everyone who should know what’s going on. The intranet wiki is a great place for that — then you have a history of meeting results that you can refer to.

The problem isn’t always due to short-term memories (possibly salespeople only remember as far back as their last commissions). Sometimes memory is selective, especially among management.

On a video game project where I was the sole programmer for a specific platform, the president of the company asked if we could develop an interactive previewer for that package. I responded that we didn’t have the manpower to do that and stay on schedule — if it was important, we needed a tools programmer. Yet that topic kept coming up — either she kept forgetting my answer or thought I would eventually forget.

And if you do have someone record the meeting results, make sure the recorder can do so reliably. Case in point: one of my coworkers who was regularly aggressive in pushing his own agenda was all too eager to record our weekly meeting results. Somehow, the meeting minutes always indicated his opinions had prevailed.

Having a fictitious record of a meeting is even worse than having no record.