(This post is the second in a three-part series on Meetings.)
If you haven’t read the previous post, Why Meetings Don’t Work, I suggest you do that first. It covers some of the common problems associated with running meetings effectively.
The whole point of having meetings (face-to-face) is to make progress on your team projects. Sometimes you need input from others before you can move forward; other times, you need to make a decision on an important issue that requires interaction with others. Either way, there has to be some kind of information exchange in real-time that has to take place before you can move forward.
Meetings can be crucial in moving an important issue forward. Use meetings only when you need to make a decision of some kind or when you need everyone’s input on what’s next in a given project. Basically, hold a meeting when input, interaction, and feedback is required for some kind of decision that involves everyone.
If and when you must have a meeting, these are the best practices to follow before, during, and after the meeting:
I’ll assume that you already have some kind of charter defined and practiced by your team if you’re working together on a project over an extended period of time. For more information on designing a charter, please read the preceding post.
If this is just a one-off project in the short-term, then designing the charter may be overkill for you. In that case, quickly figure out (as a team) the ground rules for seeing the project through to completion.
If the meeting is ad hoc, then you don’t have to design a charter, but you still need to be acquainted with the process and the process skills needed to work with others.
To begin with, invite as few people to the meeting as possible. The fewer the better. The fewer members, the higher the chances of getting the project to completion. Try to keep the team to 5 members or fewer. Send out invites to them with a time and an agenda along with the duration of the meeting. Be sure to have the following things covered:
- What is the purpose of having this meeting?
- What is the agenda?
- Who will facilitate the meeting?
- Who else will be attending (in the case of ad hoc meetings)?
- When/where will the meeting take place?
- How long will the meeting be?
All these questions have to be answered before the meeting takes place.
The first step to finishing the meeting on time is to show up on time. The next thing to know is to start the meeting on time. I know this sounds so obvious, but most meetings don’t start on time.
Assign a time-keeper who will keep track of time and keep the facilitator on track to cover everything listed in the agenda in the time available. The facilitator can also act as the time-keeper or a second member of the team can volunteer.
The facilitator can choose to start the meeting with a warm-up. I wrote about the concept of warm-up broadly in The Warm-up. I also wrote about it in the context of meetings briefly in Morning Pages, why that’s important, and how you should practice it at the start of every meeting.
Because design work is team-based, warm-up is an essential part of team meetings, where a meeting starts with a brief warm-up question that one of the team members comes up with. Then, each of us would take turns in answering that question. It wasn’t so much about the question itself (which could be something as simple as “How was your day?”), but more about the ritual of doing it.
The warm-up was essentially a trigger for us to acknowledge that we were in transition. It was about giving ourselves the permission to let go of what we had on our minds before we convened (leaving any emotional baggage or what have you) and got into the real design work as a group.
The warm-up essentially acted as a bridge between the “outer world” (our scattered “monkey brains”) and the “inner world” (the “real work”). It was vital to our team-based work process.
The next step would be to finalize the agenda: this is best when sent out by email before the meeting. In addition, in the meeting, be sure to get everyone’s feedback if something more needs to be added besides what’s already included in the agenda. Once the agenda is finalized by everyone, the team can help the facilitator to determine the order that the things should be covered (for instance, from most to least important). Also, the time-keeper should ensure that the agenda is realistic with keeping the time constraint in mind. Now, this process of determining the agenda might seem long-winded, but in reality, it’s much quicker.
After figuring out the agenda, the facilitator starts with the first thing on the agenda, and then the team processes the list, item by item, all the way to completion. That’s it.
Assign a team member to capture the ideas during the meeting. This can be the facilitator or a second team member. These ideas can either be ideas, action steps, reference ideas, or just backburner items for future. The point is to capture it all, and then later decide which idea goes into which category.
Towards the end of the meeting, make sure there is enough time to debrief and for review/reflection. Be sure to capture any actions steps based on what was discussed in the meeting. Figure out who will do what and by when.
Later, send a follow-up email to attendees to keep track of what was covered in the meeting, the action steps decided on, and who’s doing what and when. Even better, use a real-time visual dashboard of some kind to keep track of actions completed, actions in progress, and those on the backburner.
In my experience, the number one reason why most meetings fail is that team members diverge and converge at the same time, though they don’t know that that’s the problem.
Think of divergence as a mindset or a mode of thinking where you’re using your right brain to ideate — you’re open to ideas without judging those ideas. Deferring judgement till later is the key. Divergence is about quantity; it’s about freedom to express your ideas without having to worry about what to do with them or what others might think of them.
Convergence is a mode of thinking where you’re using your left brain to analyze those ideas or think them through logically, so to speak. Convergence is about quality. This is the mode in which you’re free to evaluate the ideas and/or look at them for what they are. As a team, you can even design a criteria of some kind to evaluate those ideas.
Let me illustrate with an example of how this would work in a meeting. Let’s say one of the things on your agenda is to come up with ideas for a new product/service. How would you do that? Well, the thing to note here is that you can’t have a good idea unless you have a lot of bad ideas. In other words, having bad ideas is a precursor to having a good idea. Or, think of it this way, the quantity of bad ideas builds to quality in a good idea. The mode of thinking that produces those bad ideas first is divergence. The mode of thinking of producing that good idea as a result of diverging is convergence. And the key thing that separates them both is the process skill of deferring judgement.
You can’t come up with ideas (divergence) and be critical of them (convergence) at the same time. This is not one process, but two modes of thinking. They’re fundamentally contradictory. They’re meant to work alongside each other. Divergence always precedes convergence.
Process skills include divergent and convergent thinking along with appropriate deferral of judgement. These are important skills to practice in meetings. The key, of course, is to know when you as a team are diverging and when you’re converging. That will set a lot of things straight.
Process skills mean so much more than just those things. Process skills are how the team functions together, but they also include things like interpersonal skills. If process is the “How”, then process skills are the skills that help you do the “How”. Every team requires its own set of unique process skills. Empathy is another example of a process skill; i.e. having empathy for fellow team members. Another process skill is openly sharing and bringing your whole selves to your team. There’re many other process skills such as how you structure your meetings, etc. but I’ll cover that in a later post.
Also note that the application of this process goes beyond the context of ideation or meeting, which I’ll also cover in a later post.
Ultimately, a meeting is a type of tool in your arsenal; it can work (or not) depending on how you use it. When you have the right process, the right process skills, a well-established charter that works for you and your team, that’s when you can run them effectively. When you master the process of working well with others, amazing things can happen as a result.
In the next (final) post, I cover some of the best practices that you can use in meetings and some final words to wrap the three-part series.
