Ok, so you've just had (yet) another meeting, and you left it feeling dissatisfied with the results, with words like "useless", "time waste"coming to mind (as well others much less "diplomatic"). What can you do about this?
Much has been written about the subject of "effective meetings", especially around facilitation techniques. While it's certainly true that many meetings I've observed could use better facilitation (in order to allow participants to focus and stay on topic, make sure all voices are balanced and heard, etc.), the main problem I often see is around lack of clarity on the purpose of the meeting: there's often a stated purpose (more or less explicitly indicated when the meeting is called), but if you observe the conversation closely, you start noticing how (sometimes very subtly) the meeting morphs into a different purpose, or keeps jumping between different purposes.
When I see this happening, I try to classify the conversations into different "buckets", and then try to determine which was the "main bucket" this particular meeting was intended to go to.
The "buckets" I suggest using come from the observation that to effectively manage the delivery of projects and services we usually require 4 different types of conversations to take place:
#1) Conversations about the status of work currently in progress: we need to know where work we've started and committed to deliver is at, what's impeding its flow, etc.
#2) Conversations about starting new work: we need to determine what to work on next, when the right time to start it might be, etc.
#3) Conversations about releasing work we have finished: we need to put the results of our work in the hands of our customers, and that often requires additional work that also needs to be managed (planned, executed, controlled, etc.)
#4) Conversations about understanding the process we follow to do the work, and ways to improve it: these are the well known "inspect & adapt" cycles.
An important note: I refer here to "effectively manage delivery"; there are of course conversations about the work itself, its meaning, clarifying and deciding how it will be technically done, sharing knowledge about it, etc. Those correspond to the "doing the work" general compartment, not the "managing the work" compartment, where the 4 categories listed above apply.
(* A LESS IMPORTANT SIDE NOTE: strictly speaking there are 3 additional "conversations" that are often needed in the "manage the work" world, but they apply at larger scales so I'll leave them out for the moment. If you're interested in those, let me know in the comments 😉 *)
So, you walk into that dreaded meeting...
First, determine if this meeting is meant to be the "doing the work" or "manage the work" compartments.
If it's the former, then you'd expect a detailed discussion on the work itself. If you're doing something like Scrum, this is what "Refinement" or "Grooming" sessions are meant to be. Other ad-hoc meetings about architecture and design, specific problem solving, and "hands on" work would fall in the same category.
If it's the latter ("management" meetings), then try to asses which of the 4 "buckets" this meeting is, in principle, part of. Again, if you're doing Scrum, then you'd expect, for example, that Sprint Planning would fall into #2, while your daily stand-up should be mostly about #1. For other, ad-hoc meetings, just try to find the closest match based on the name or stated purpose of the meeting.
As the meeting takes place, keep track of the conversation and to which "bucket" it belongs, and more importantly, whether it deviates and moves into some other category.
You might notice that, for example, a meeting called under the title of "Demo current progress" starts with an actual demonstration ("doing the work") but suddenly someone asks if they shouldn't be working on some other feature that they notice missing, and then suddenly the conversation pivots to deciding when that work will be started (#2), only to be interrupted a few minutes later by a question about that demoed work and when it will be available in the production environment, which causes the conversation now to move into decisions and considerations related to first, a deployment into UAT, announcements to the user community, involvement of other stakeholders, all of that then followed by a production release (now we're in #3). So, a meeting that started in the "doing the work" world suddenly moved into "managing the work", and jumped across different categories once there.
So, what's the problem?
Arguably, all those conversations were needed. The problem is that different categories of conversation require different people, different information, different decision making ability, etc. They may also be appropriate at different times, on a different cadence, etc.
When we allow meetings to jump categories this way, there's no way we can guarantee that all those preconditions are met: we end up with the wrong people in the room, for example, or without the needed pieces of information to make the decisions that are required, or with people who just don't have the authority to make them, etc. Not to mention that different people will also have different interests and knowledge, and that will impact their ability to actually follow the conversation as it moves from one category into another.
OK, and now what?
The answer to that will heavily depend on your ability to steer these meetings: are you the facilitator of the meeting? are you in a position to design how this meeting will run, or are you just an invited participant?
When designing a meeting, ideally we want it to be focused on a single purpose. Then we can make sure we have the appropriate people, with the right information and authority, the proper timebox and facilitation format, etc. So, once you've collected enough observations about the conversation flow in several meetings to "be fixed", perhaps you can redesign them with these guidelines in mind. Taking a systemic view is important here, since usually after a while it's not enough to "fix" individual meetings, and instead we need to understand the larger picture.
Often times, however, single-purpose, very focused meetings are not feasible, especially when initially we're trying to "fix" a whole bunch of meetings that got progressively unfocused over time, with people extremely busy attempting to go from back-to-back meetings and facing the proverbial "solid wall of outlook blue". In cases like this, my suggestion is to make sure meetings have clearly defined sections, with a single purpose each. It's the facilitator's job, then, to make sure conversation stays in the appropriate "bucket", noticing when a pivot is about to happen, and use some mechanism to defer that to the appropriate time.
This also applies for cases where organizations have meetings as a matter of "process", or even "tradition", that renders them vulnerable to this "mixed conversation" problem. The Sprint Review is an example of this case, which can mix aspects of #1, #3, and even #2, depending on how the organization decides to run it.
If you're just a participant, you can still attempt to map the multiple purposes the meeting is trying to address, and then decide which one is for your and which one is not. Maybe you can bring this to the attention of the facilitator, asking to go back to the original purpose. Or you can bring your observations to the owner of the meeting, pointing them to this article as a hint that they perhaps could do something about it. 😉
Comentarios