I just has a mad morning of scheduling meetings. I could hear the disappointed sighs from co-workers in nearby cubes, while others immediately responded to the meeting requests with what seems to be...joy. Meetings are a necessary evil in the managing business, and are often abused to the point where the meeting itself seems evil. This is not to say that there are not some inherently evil meetings--entities that have taken on their own lives and must be stopped--but this entry isn't about those. It's about using meetings as a tool to be effective.
I once managed an external vendor. They didn't do well with dates unless those dates were punctuated with meetings. Meetings were where they knew I would call them and politely pester them until I get what I want (my promised deliverables). I was rarely harsh--don't threaten to fire someone, for example, unless you're not planning on ever using them again. But I was essentially the height of politeness. This is because you can hang up on an angry person. However, most people are wired to be nice to someone who is nice to them, so when I called they were stuck--they either had to explain to me why they didn't have what I asked for and they said they'd give, or have it at that time to avoid the guilt/disappointment I would express to them, in kind and assuring tones.
We can talk more in later blog posts about using people's natural emotions to get them what they want--and in turn get you what you want--but this post is about using meetings as a tool. My example above uses the meetings to box in time frames and help my external vendor meet dates.
This method doesn't work for all occasions.
Your immediate co-workers, boxed in the same position, will get grumpy, wondering if you don't believe them when they tell you when they'll have something to you. So, instead of a specific meeting with a specific person, you want to set up checkpoint meetings with the whole team; that way people don't feel singled out, but do feel a little peer pressure to deliver. In Agile/Scrum, these are daily meetings, 15 minutes or less. I don't recommend that status meetings ever go over a half hour. If you want status & to discuss some issues, do status in the first half hour, and then let people go who don't care about the issues that they want to discuss in the second half hour. People will LOVE you for this.
Allow me to reiterate: status meeting should be their own beast, with their own rules, to be truly effective. There are always people who will happily drone on and on and on about their project. When they are done 25 minutes later, the person following them may say five words, and considered himself done. Neither is a useful type of status; eg: "...and then I had green beans, and then a Diet Coke, and then compiled the code, and we were done!" Um, Thank you. Next? "Everything is totally fine." Riiiigghttt...
My recommended rules for status meetings:
1) Set an Agenda before anyone comes to the room. This is a status meeting ONLY. Set up a separate meeting for further definition of issues.
2) Set a time limit. For example, the meeting is only 20 minutes, so each of you will have 60 seconds + around 60 seconds of questions (if that time is needed).
3) Answer only the following questions: 1) Status of your project is red/green/yellow, 2) why, 3) is there anything on which you require help/are blocked (if so, what)? You can certainly add in your own or switch out questions, but never more than three in a status meeting to keep it short.
4) For folks that need help, we'll schedule appropriate follow up meetings. Don't feel you need to work it out in status unless its gonna take under 15 seconds.
5) Reward people for ending on time or early; eg: everything from "you get some time back!" to "if we can get this done in under 20 minutes, I'm taking you all to lunch." I've offered board games, door prizes, etc. It helps set the norm for the team that being on time and finishing on time is the way things are done. It also saves a LOT of drama.
In Agile/Scrum, the questions are slightly different and the meeting is typically 15 minutes or less. I could do our daily stand up in 10 at one company, even though I had 14 people reporting. Mind you, we were attempting to go for our best record, which is how we got it down to 10 minutes. Note, we still didn't lose any productivity from doing it this way. Which was AWESOME. Some people, however, find that your lead Quality Assurance tester holding a stop watch a little distracting while they're trying to report.
Hand off reminder meetings are also quite useful internally; they let people know when data they are interested about is coming in. Just be sure when setting up the meeting to set the time for the participants as "Free" and then they'll get a pop up that both has the data they've been waiting for and which doesn't mean they have to actually go anywhere! A big win all around.
I am also a big fan of the explanatory meeting (which is never held in a status meeting, but might happen after). Basically, you receive a doc or a set of instructions (or you provide one). A follow up meeting allows you to focus only on the participants who need to know, and allow you to go over the materials. Its important for explanatory meetings to ask people to read the material ahead of time, and it's important for your blood pressure to know that only about 20% of them ever will. Plan time into the meeting for them to read and review the document. Sometimes explanatory meetings are the ONLY way you can be sure someone will read the document. Use them judiciously, and, as noted, make them very targeted. I also recommend they never last more than an hour--if you need to schedule another, you totally can. But human beings burn out on docs after an hour or so.
That is it for the wisdom of today. I know you are shocked, but now I have a meeting to go to.
No comments:
Post a Comment