How to run a successful developer meeting.

By Peter A. Bromberg, Ph.D.

Peter Bromberg

I've been both a developer and a manager in my successful high - technology career. If you are a developer or manager in a corporate environment, either small or large, and you have ever been asked to attend a meeting, then what I have to say here should resonate loud and clear!

Let's get to the point: the best way to hold a successful meeting is to have NO MEETING AT ALL. Period! In this day of intranet discussion groups, email distribution lists and other excellent means of group information dissemination, if you are charged with deciding on holding a meeting then the very FIRST THING that should go through your mind is "Do I really need to have a "meeting"? Is there a more efficient way to promulgate (and receive ) this information? Most times, you should be able to come up with an answer that indicates a meeting is not necessary. Once a meeting has been decided to be called, you can pretty much bet that, from a productivity standpoint, you (and your "group") are going to be on the losing end 95 percent of the time.

Having said all this, meetings are a neccessary evil. If you decide that you have to have a meeting, then at least do yourself (and those poor souls around you who are doomed to participate, usually against their will) a favor:


1) All meetings should have a stated start and end time, and stick to those times religiously. You will gain the respect and admiration of your peers, superiors, and subordinates if you do this. Remember that the average attention span of a human being is about 45 minutes. If your meeting (which probably shouldn't have been called in the first place, remember?) has to run more than 45 minutes, man, you better have one hell of a good reason for it!

2) Every meeting should have a specific agenda, and that agenda should be distributed to all participants ahead of time, either via email or other written communication. With a track to run on, your meeting will, by its very nature, be more productive and there will be less chance of throwing it "off course" on some unrelated side topic for 30 to 45 minutes.

3) Handle off-topic and off-agenda items properly. If somebody has a valid concern, but it is not germane to the subject and agenda, offer to hear the item AFTER the meeting so everybody else can get BACK TO WORK.

4) Provide a meeting summary to all participants, and invite feedback. Get somebody to take notes during the meeting, type them up, and send out an email to all the participants. This follows the age-old speaking formula, "Tell-'em what you're going to tell 'em, then tell 'em, then tell 'em what you told 'em." This provides benefits in terms of communications continuity that can pay big dividends over time, and foster a more productive group mentality.

5) Only invite participants who need to be present. I cannot count the number of meetings I have been asked to attend where 11 or even 15 people were asked to drop their work to be present at a meeting where 90% or more of the actual work could have been effectively handled by only three of the people in attendance, and the rest kept informed via email. Think about it. Are you calling 155 people into a meeting because they are all relevant to what is supposed to be accomplished, or are we doing this to exercise our "ego"?


Well, I'm sorry but I have to cut this rant short -- I'm late for a meeting...



Peter Bromberg is an independent consultant specializing in distributed .NET solutionsa Senior Programmer / Analyst at in Orlando and a co-developer of the developer website. He can be reached at