In writing this series, I thought it would be fun to talk about all the non-coding issues that we have to deal with in our day to day jobs. It's not unusual for me to spend all day coding, and then all evening writing yet another system. I thought the break from semicolon delimited lines would provide a much needed break. While all this is certainly true, there are some topics that might seem mundane at first glance but need attention nonetheless. Such is the case with the lowly and oft despised meeting.
I'm sure there are very few of us in this business who haven't grumbled on occasion that it seems like all we ever do is sit in endless, pointless and unproductive meetings, with little being resolved beyond when the next meeting is and who buys the donuts. Even so, it is impossible to bring software to life and to market without them. There are many stages in software development including requirements gathering, design, implementation, testing and even the occasional food fight. All of them require meetings.
If you're unfortunate enough to find yourself in continual gatherings with Marketing listening to hype and unrealistic feature lists, or worse still, those pep rally meetings with Some Important Vice President who delivers hokey talks in Corporate-speak, peppered with references to Mission Statements and other equally irrelevant references, you have my deepest sympathies. However, if you find that many of your meetings are by programmers, for programmers and many of them are held at your bequest to work through various technical details, I think I can help get you in and out in time to actually get some coding done. Who knows, you might even finish up in time to catch a ball game after work.
Like any other aspect of our trade, conducting meetings is a skill that can be developed. You simply need to have a goal in mind and attack the basics. Probably the most concise summary of our goal is to get the information we need and then get out, fast. There may be a footnote in there somewhere about knowing when to duck should a pizza throwing contest erupt, but that's purely incidental.
The first rule of efficient meetings covers duration. No meeting ever lasts more than one hour. Period. Break this rule at your peril. Now for those of you who have squirmed through meetings lasting two, three, and sometimes even eight hour meetings, that may seem like an unrealistic limitation. You have to have enough time to cover the material, and how much can you really get done in an hour, right? Actually, you'd be surprised how much you can accomplish in just sixty minutes providing you streamline your approach and handle yourself in a disciplined and orderly fashion. Further, any meeting longer than an hour is going to lose your audience and productivity will suffer severely. Folks just aren't cut out to sit in those conference room chairs and listen to others drone on for much longer than that, and the attention wanders as impatience grows.
So how do you keep meetings down to an hour and still get things done? It begins by setting the scope of your meeting beforehand to encompass a very small number of items, preferably on the same general topic. Don't try to tour the world in a single meeting. If you need to discuss database layout and also user interface issues, break them into two meetings. Why not just cover them in a single two hour meeting? Fatigue is the first reason, and not one to be underestimated. Tired people are less efficient and you'll get less done. Secondly, when you have a meeting that covers more than one topic, you'll inevitably get drift back and forth across previously discussed topics as the meeting goes on. This dilutes your focus and causes many time consuming and unproductive digressions. Pick a topic. Hold the meeting. Get in, and get out. Focus is everything.
This means that you need an agenda, and it needs to be distributed prior to the meeting to all participants. Think in terms of a short bullet list of the items you're going to cover. You also need goals. Exactly what do you wish to accomplish from this meeting? Have your deliverables clearly in mind before you even distribute the agenda. The list of items to cover should be composed with your desired goals in mind, and should communicate that to the reader intuitively. For instance, instead of an item reflecting that you want to discuss the order entry database, make your desired deliverables a part of the topic by saying that you want to finalize the layout for the billing information table and to define how it interacts with the non billing information table. That tells people what technical thoughts they need to bring to the party and what you're looking to get out of it. It will go very quickly as a result.
In addition to distributing the agenda for the meeting, you also need to hand out any supplemental reference documents, such as the current table definitions for the previously mentioned database. Make sure you get these to the attendees as many days prior to the meeting as they'll need to digest it. Nothing is more irritating than sitting in a meeting where nothing is getting done because everyone is reading the document they've just been handed. That means that if you're an attendee, you need to do your homework before the meeting. Make a list of your ideas, thoughts, technical problems, etc. and have a concise list of these printed out and in front of you when you sit down at the conference table. The better prepared everyone is, the less time you waste thrashing about and spinning your wheels. Think of it in terms of a surgical air strike. You want to hone this process so that everyone can go back to what they really like doing with their day, which probably involves generating a few compiler errors.
There are two positions that must be filled in each meeting. The most obvious one is that of moderator. This person is in charge of running the meeting. Very often, the moderator won't even have anything to present. It doesn't have to be the same person each time, and the position doesn't have any regard for rank. It doesn't matter who fills this post, a manager or one of us worker bees. It's just an organizational job. Once the meeting begins, though, the moderator is the law. If you want to wear a cowboy hat and a couple of six shooters to help enforce that notion, be my guest. No one said meetings couldn't be fun. They just rarely are.
The moderator has a number of responsibilities to fulfill. First, it is the moderator who assembles the list of topics to be discussed and sets the order of discussion. This person will open the discussion on a topic, and ultimately decides when to close that issue and move on to the next. One of the more valuable purposes that they serve is to keep dead horses from being overly beaten. Horses like that sort of thing. All too often, several factions will argue back and forth covering the same ground ad infinitum, neither side able to convince the others. At this point, the moderator firmly declares a glue factory and tables this item for a future meeting, to allow further preparation and hall meetings to facilitate progress and to keep the current meeting productive. If you're a moderator, don't be shy about this. It's a crucial task that you must perform if you're to keep the meeting beneficial to all concerned, even the protagonists. Move on to something that you can resolve.
To keep things organized and avoid the shouting matches that can occur when people are trying to get attention, the moderator recognizes who has the floor. If you ain't got the floor, then sit down and shut up. It helps the flow tremendously, and everyone will get their turn. It is imperative that everyone recognize the authority of the moderator, or chaos will ensue. That means yet another long, unproductive meeting that will just have to be repeated because nothing was resolved. The moderator also has the power to declare that due to time constraints a particular topic will not be discussed in this meeting but tabled for a future one. It is also imperative that the moderator keep an eye on the clock and not allow the meeting to run late.
The next position we'll discuss is a thankless but important one, that of the scribe. How many times have you attended a follow up meeting, only to find that half the people don't remember the outcome of the last one and the rest all hold differing opinions about the results? The scribe eliminates this problem. This person is the one tasked with keeping notes for the entire meeting, and it's a very good idea to select someone who is not a presenter on any given topic. This frees up the other participants to concentrate on the discussion and not worry about keeping bad notes that they'll just be unable to decipher later anyway. Rather than having many sets of poorly written and contradictory notes, the scribe types up the results of the meeting and circulates the summary to all attendees within one hour of the close of the meeting. The one hour time frame is there because it's important to do this with the meeting still fresh in your mind. One of the primary notes that the scribe maintains is a list of action items, that is, who gets tasked with what work and when it's expected to be turned in. This is one of the major deliverables of the meeting.
While it's acceptable to have the scribe participate in the discussions, this should always be secondary to the keeping of notes. For this reason people will often bring in someone for this position who doesn't have direct input into the topics at hand. It's tedious work and believe me, if you want to keep friends in the company, you'll rotate this position.
When the meeting convenes, the scribe gives the moderator the summary of the most recent related meeting on this topic, should there be one. This is then read to everyone as a refresher. The moderator then announces what the topics will be for this meeting, in order, and gives the floor to the first presenter. It's not uncommon for the presenter to also be given a time limit to keep things moving.
Methods for being recognized by the moderator in order to gain the floor will vary with the style and members of the organization. Allow the moderator to set this in the beginning, and then let it follow a natural course that everyone will be comfortable with. The aim is to keep things organized and efficient, not to get bogged down in mindless formalities and protocol that serves no purpose beyond sounding important. Remember, you're here to get issues resolved and then be on your way.
At the end of the meeting the scribe will quickly go over the list of action items that were taken and will also summarize the decisions that were made. For the most part, if it wasn't a decision or a work assignment then it really doesn't qualify as output of the meeting. The moderator then dismisses the meeting and everyone dives for the last piece of pizza that was somehow overlooked in the heat of the moment.
I didn't come up with these ideas, and in fact there's not an original idea in the lot. I learned this by working for people who really had their act together and didn't mind sharing their techniques with an inquisitive mind. It works, folks. I've accomplished more in meetings of this type than in months of meetings at other companies. You have to show some discipline, but in the end it really does dramatically reduce the amount of time you spend away from the compiler. So get in, get out, and then go catch that ball game.
Top 