In the last post I talked about attending meetings. The flip side to that is running a meeting. Sometimes you’ll go to a meeting and it turns out to be a waste of time. Minimizing that is an admirable goal, but you can’t always tell if it’s going to be a waste until it’s almost over. There should be no reason, however, to call a meeting that turns out to be a waste of time. If you call the meeting, you need to run the meeting.
Running a meeting well starts in advance of the actual meeting. You need to know what you want to get out of the gathering and then put a plan together that can get you there. The short version is Goal + Plan = Agenda. If you don’t have an agenda, you are overlooking one or both of its parts.
Next is the attendee list. With agenda in hand, this should be a breeze: it’s the list of people who need to approve of or execute your plan. As you look at each attendee on the list, you should know what it is you want them to do post-meeting. This should then be conveyed and committed to during the meeting. If you don’t know what you want someone to do post-meeting, then (once again) you’re lacking clarity in either your goal or your plan . . . or that person doesn’t need to be invited.
Now that the "plan your work" phase is over, the next part is easy: "work your plan". The actual meeting should be a breeze: work your way through the agenda, record any newly revealed information, ensure that everyone is clear on what’s next, and get commitment on all of the planned tasks. Keeping things on track is a lot easier when everyone knows where the track is.
If I had to guess, I’d say that anyone reading this has been to the type of meeting I’ve just described. I’d also guess that it represents a small percentage of the meetings you’ve attended. Further, you probably didn’t walk out of one of these thinking, "Wow, that was a great meeting!". Instead, you most likely forgot about it because it seemed to be a logical extension of your work. Contrast that to the "other" meetings – the ones the represent the majority that you’ve attended. There’s a good chance that you walked out thinking, "That was a waste of time".
Don’t be the one who wastes other’s time. Plan your work and work your plan or, as a very real but seldom used option, don’t call a meeting.
Like any other part of your job, going to a meeting is worth doing well. The key is not so much what you do, it’s what you don’t do:
1. Don’t take the meeting off track. Even if you’re every bit as funny as you think you are, save it for later. 2. Don’t work on your laptop. If you don’t need to be at the meeting, don’t go. If you need to be there, but lose interest in what’s going on, bring things to a close. 3. Don’t start side conversations. Even one of these can distract everyone else. More than one and no one can hear anything. 4. Don’t yawn, close our eyes, roll your eyes, snicker, or any of the other passive aggressive favorites.
Okay, after 4 "don’ts", things are sounding pretty negative. Here’s a "do" and a parting thought:
1. Make it worthwhile for everyone (yourself included) to have you in the room.
Once again, like every other part of your job, the time you spend in a meeting is time out of your life. Time you won’t get back. Make it count, or spend your time some other way.
Developers make more mistakes than any other profession I can think of. The editor you use finds some. Your compiler finds some. Your unit tests find some. Static analyzers find some. The QA team finds some. And, as we all know all too well, your customers find some.
I was recently talking to a friend and co-worker about developer mistakes and we reached a valuable conclusion: senior developers don’t make rookie mistakes. The result is that it appears that they make fewer mistakes, but the quantity isn’t what’s important. Senior developers don’t necessarily make fewer mistakes, they simply catch them sooner. No else sees the majority of their mistakes because of the way they perform their work. Senior developers know what it takes to deliver good software and at the critical decision points, they do what it takes to keep things on track.
Ask yourself: When was the last time you made a rookie mistake? If it’s been a couple of years (or a couple of projects), then chances are that you’re firmly in "senior-level" territory. If you’ve made any in the last few months, though, then you might want to spend some time focusing on the way you work instead of adding new tools or techniques to your repertoire.
Like other craftsmen, the Big Swinging Developer has an above average toolbox. When a problem rears it’s ugly head, the right program, utility, or plug-in is just a download away. Like a master craftsmen, Big Swinging Developers also realize that tools are there to perform a function and that there’s more than one way to complete a task. When you’ve reached this level of mastery, you stop complaining that your client uses ClearCase for version control even though you prefer Subversion. You’ll gladly work with Oracle, SQL Server, or MySQL . . . after all, databases are just a tool that let you work with data. You’re a fan of Infragistics, but they’re a Syncfusion shop? In the words of Tim Gunn, "Make it work".
This is not to say that you shouldn’t have preferences. And you should certainly put in your two cents when they’re in the process of making technology decisions. After the decisions have been made, however, it’s time to get down to business. Remember: It’s a poor craftsman who blames his tools.