The 7 Steps of Software Development - Revisited5 Development Team Productivity Killers

Conquering Meeting Madness

July 14th, 2007

Meeting MadnessMeetings are the bane of their existence for many a programmer but they’re often a necessary evil, particularly if you’re a lead developer. What steps should you take in ensure that your meetings are worthwhile and don’t waste everyone’s time? When should you call a meeting and when shouldn’t you call one? Should you have regularly scheduled weekly team meetings? What time of day is best for scheduling meetings? In this article I’ll examine these questions.

When should you call a meeting?

In general, a meeting is called for when one or two people need to provide information to a larger number of people quickly or when real time interactivity between participants is required.

Here are some situations where a meeting is called for:

  • When there is a need to convey sensitive information at the same time to a number of people. For example, management or other organizational changes, layoffs, work policy changes or other confidential or sensitive matters.
  • A demo or training session on a new tool or product.
  • When the subject at hand would benefit from a meaningful, interactive, discussion by those invited to attend, for example, a joint application development meeting.
  • A brainstorming session to solve a problem that could not be resolved by other forms of office communication.
  • When key meeting participants are only going to be in the office for a short amount of time, for example, a meeting with a consulting team or vendor.

Here are some situations where a meeting is NOT called for:

  • To communicate work status to other members of a project team
  • To deliver project status to project sponsors
  • To make it easier for a manager to keep tabs what everyone is doing
  • To ask and answer questions like, “What have you accomplished this week?”
  • To hand out work assignments

What about having regularly scheduled weekly or bi-weekly team meetings?

My take on this is that these meetings are a waste of time. In most cases, very little information is exchanged, programmers hate the disruption of their work routine and thought processes, they are ineffective for team building and managers or meeting sponsors often feel that they have to fill in the time block with something, even if it is trivial. Also, lazy managers will use them to gather status reports and to pass along information to individuals rather than the team as a whole.

My advice is to avoid calling for any regularly scheduled meetings. Instead, gather status information and make trivial team and company announcements either individually in person or through email or an online forum/blog/wiki format.

What time of day is best for scheduling meetings?

If you must schedule a meeting avoid scheduling one during the middle of the morning or middle of the afternoon. When you do this, you almost guarantee that you will disrupt the work flow of all of the attendees for that half of the day.

Some people recommend meeting first thing in the morning or at the end of the day. This works sometimes but you have to be mindful of individual work schedules and the commute situation in your area. For example, you don’t want to schedule an 8:00 AM meeting when some of the participants regularly arrive at 9:00 since they won’t be there and having the meeting later will disrupt the morning for the early birds. The opposite applies to late afternoon meetings. Also, early meetings can be unexpectedly disrupted when people arrive late due to commuting difficulties, a common problem in most larger cities.

Scheduling just before or just after lunch is generally better since it avoids disrupting the work day as much. However, people will tend to be distracted as lunch time nears and stomachs begin to growl. After lunch works good although some people tend to be a little lethargic at this time.

My favorite time for meeting is lunch. If the matters being discussed aren’t too confidential or don’t require props in the office, take everyone out to lunch at a favorite restaurant. Perhaps you can even get a place with a small meeting room. If the meeting needs to be in the office, order in pizza, Chinese, sandwiches or the like. A free lunch is appreciated by all and people will view it as a nice perk and a long lunch rather than just another boring meeting.

What steps should you take in ensure that your meetings are worthwhile?

Here are some steps you can take that can help you have an effective meeting:

  • Before you call a meeting know what you want to accomplish with it before you call it. If you don’t know or are not sure, postpone it or call it off until you’re ready.
  • Have an agenda and stick to it. Often meeting sponsors will allow the meeting to stray off topic. Avoid this trap by having clear discussion goals that are known by all attendees in advance and by keeping the discussion focused on the topic at hand during the meeting.
  • Achieve the goal of the meeting, even if conditionally. Don’t use the lack of a concrete decision in one meeting as an excuse to schedule yet another meeting. Instead, reach a conditional consensus and an agreed upon follow up plan that doesn’t require more meetings.

One final idea

If you’re the lead or manager, don’t use the meeting to hand out tasks. This tends to make meetings more dreaded by your team and tasks assigned this way tend to be incomplete and vague. Instead, follow up the meeting discussion with emailed or one-on-one in person assignments. You’ll find this to be a more effective use of your personal time as well as the team members.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Development Teams


Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (2 votes, average: 5 out of 5)
Loading ... Loading ...

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed


Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives