In Collaboration Explained: Facilitation Skills for Software Project Leaders there’s a whole section on different types of meetings, what they are for and how they work. I read it and thought, ‘Everyone knows how to run a meeting, surely?’ Having said that, I’m spending a lot of time in and chairing meetings at the moment, and actually it wouldn’t hurt to brush up my skills.
The author, Jean Tabaka, defines five types of meetings:
- Status meetings;
- Planning meetings;
- Working sessions;
- Retrospection meeting (post-implementation review); and,
- The meeting that shouldn’t have happened.
In my projects, most meetings fall into the first two categories, although sitting down with someone to plan is also ‘work’ in my opinion. Tabaka has some interesting ideas to add to your meetings once the team is “ready for some diversity.”
She suggests starting status meetings with a song to see who can guess the title and artist, or for each team member to bring in a joke. Her idea of creating a team theme is quite interesting but I can’t see it working in the UK. Giving everyone names of fish and having ‘Molly Flukehausen’ give a status update would go down like a lead balloon over here, which just goes to show how culturally-specific team building exercises can be.
The meeting that shouldn’t have happened is ironically the most relevant to project management. We should be all about making great use of everyone’s time, accurate resource planning and weeding out pointless, time-consuming activities.
But that’s not how real-life works. Unfortunately, there are plenty of meetings I attend that don’t move my understanding or work forward at all.
For a long time, I thought departmental team meetings were a waste of time. Six of us would sit in a meeting room, and do the creeping death of reporting on what we had done that month. Given that we all sat near each other, socialized, ate lunch and spoke to each other during the day, none of what was discussed in that meeting was ‘news’.
It took me a while to realize that it wasn’t what we were saying that was important in that context: it was the fact we had bothered to get together formally at all. It helped the quieter members of the team understand the wider picture; it allowed those under pressure an informal opportunity in a safe environment to vent steam about how things were going.
As we didn’t work on the same projects, this was the only time we officially had in our diaries to be together as a team. In a way, the fact that I felt the meetings weren’t helpful to me personally was a sign of how well the team was working together.
Tabaka suggests that each team member:
Must clearly see a benefit for being in the meeting versus remaining at her desk. Leaving the meeting, each participant must carry something back to her desk … that directly impacts her work. Without this clear ‘bridge’, participants see no need to be in a meeting or to actively listen and participate.
Sometimes the bridge is a list of actions, a sense of direction or the output from a post-implementation review. Sometimes, the sense of belonging to a supportive team is enough.