It was 4:00 PM, time for the weekly status check meeting. A headcount of the meeting room showed that all ten participants were on time, everyone was smiling, and no one was fidgeting. Time to start. Tom had made two UI prototypes, one using backbone.js and the other using angular.js. He described what he felt were the pros and cons of using either. His presentation was followed by a 15 minute discussion where other participants added their own experiences and concerns. Tom realized that a few more areas needed further explorations; he promptly noted them down and promised to look into them. Next up, Sally spoke about how performance had been going from bad to worse. An advanced search which earlier took 500ms was now taking over a minute making the product virtually unusable. A 30 minute discussion revealed some areas that needed to be evaluated for bottlenecks, which Vijay promptly volunteered to look into. With performance out of the way, Krista spoke next about some UI/UX changes which she felt would enhance the usability of their product. Everyone agreed that the UI sucked and the changes suggested by Krista should actually have shipped in the previous release, and her suggestions were added to the feature pipeline. The meeting ended at 5:00 PM sharp. Rick, the product manager went back to his cabin to send everyone a follow up summary of the meeting: he wrote a summary of what was discussed, created a list of action items and who was responsible for what, and added them to their team management software. With a satisfied smile, he emailed the summary to everyone which was promptly seen by the rest of the team as they were doing their final checkins, and checking emails while wrapping up for the day. Everything was great. Just another day at daydreaming.com Inc.

Meetings in real life have never been like the ones I dream about. If anything, they make my palms sweat and my heart beats a little faster, I have to rush to the coffee machine and make myself a cup of strong black coffee to keep my brain alive in the meeting. Coffee also gives me something to be occupied with while I wonder why I was invited.

But are meetings the real culprit, or is it the way we conduct them? I think it is the latter. As someone once said - it is always a people issue. But there are ways to run effective meetings. While they may not leave your team wanting more, they will certainly make meetings more palatable and maybe even useful. Here are five tips that will help.

Have a very clear agenda of what needs to be discussed in the meeting and what is expected from each the discussions. It is best to email the agenda to all the participants at least a few hours before the meeting, so they have enough time to read it. The agenda does not need to be a long writeup - no one will read it then - just a simple list of items and expectations.

I have often been in hour long meetings where I was needed for barely 10 minutes. It's understandable that one of the five items to be discussed needs a Docker.io expert. But don't ask him to participate in the entire meeting. It's much better (and more polite) to intimate him in advance that you may need him to join for a few minutes. Call him in when the item is tabled and give him the option to leave after it's done.

Context changes are extremely disruptive to a developers flow, and there are few things that disrupt flow than sitting in an hour long meeting where your real role was for about 10 minutes.

Many people love to ramble - I don't know if there is a personality type for ramblers, but if there is, it must certainly include programmers. A discussion of which color to use for the menu bar can very easily turn into a scientific debate about how colors affect the human brain and how a certain shade of Orange signifies peace and action, and how a shade of Blue gives the impression that we mean business and are here to stay. Or sometimes developers discussing a complex design issue will suddenly take a turn and lament why the programming language totally sucks and how had they been using language X, this problem would not even be there.

The amount of times I have tormented my teammates with my ramblings and how they always repaid the favor will certainly fill a book. But if there is something I have learned it is this - ramblings start of as a little joke (maybe a diversion from the drudgery of the problem) but they soon take a life of their own. If you want your meetings to be effective you will have to be merciless at squashing any attempt by anyone to go off at a tangent. Call them out gently, but call them out immediately and steer the meeting back to its original purpose.

Sometimes it's 45 minutes into a hour long meeting which has 5 items on the agenda, and we are still at item #2. The meeting has a clear agenda, only those who need to be in the meeting are there, and no one is rambling. It's nobody's fault but discussing why feature X is not working on client Y's setup can just take that long. No one knows in advance how long it's going to take. It could be anywhere from 5 minutes to 5 hours and sometimes god forbid even 5 days. How does a manager even create an agenda when a large number of software issues can have this quality? There is no easy answer, but something that often works is to timebox items. Give it 15 minutes and if it feels like it's nowhere close to being resolved, then decide to have a separate meeting specifically for it.

I think all software developers are prime candidates for early onset of Alzheimer's. Maybe it's because we work in a field where things are constantly changing forcing us to keep up with a lot of information or maybe it's because we are always working in a state of partial attention with our attention being disturbed by instant messenger, Twitter, and coworkers. Whatever it is, programmers are notorious at forgetting.

In the meeting everyone will have agreed how that performance bug should be fixed, but at least half will forget ten minutes after the meeting. John might have volunteered to look into the deployment issue on Amazon, but if no one reminds him he may never remember it because he probably has ten other things clamoring for his attention right now.

The only way to make sure that everything decided in the meeting will be understood, remembered and acted upon is to make a summary, send it to everyone and also put every action item in the team management software.

Meetings aren't really all that bad. I remember a time when I was badly stuck with a problem I just couldn't figure out. I bought invited a few colleagues to a shirt brainstorming meeting. Their suggestions gave me a few ideas and eventually helped me fix the problem. I also remember how as a junior developer, just witnessing how the Java guru of our team worked his mind through various issues, helped me learn a lot about how expert developers think.

So it really is a people issue. It is how we conduct meetings that make them inefficient and boring, but with a little bit of thought and discipline we can turn meetings into events that are not only palatable but also useful.