I have been asked to “drive” a meeting next week. Unfortunately, I was not asked to be involved in the discussions leading up to this meeting, which is the denouement of a long set of discussions between our management team and another management team that has a product with which we have considered integration. This is a mistake.
Driving, by the way, is one of those Microsoft (or perhaps corporate) words with special meaning. Driving means to set the agenda and ensure that the agenda is followed and the goals of the meeting are met.
To effectively set the agenda and make sure the goals are attained, you have to fully understand the background of the situation. This requires, at a minimum, that you are fully informed about the discussions, meetings, and materials that pertain to the subject matter. Better, since only rarely is there good documentation or accurate and inclusive verbal synopses of what has already been discussed, is to simply have meetings driven by someone that has been regularly involved.
Subscribe to:
Post Comments (Atom)
4 comments:
I don’t think I agree with you that a “driver” should be a participant in the preceding work. If you were an active member of one development team or the other, it would be nearly impossible to be neutral, given the enthusiasm I have seen for products and projects in your environment. Someone who can be neutral may be in a better position to get to the real heart of the matter than one who knows all the inner working of one side but not the other.
There are ways to get around the problem you addressed. In my time tested “tell ‘em what to do” manner of annoying everyone, I’ll put up an example here for you to pick apart.
If you have a smart board, this is a good place to use it. It can be useful to tie the smart board to your laptop. Take notes on the laptop (making lists, for example), then draw arrows and write priorities on the smart board. If you need to, photograph the board with a digital camera.
Tell both groups in advance that you will open the meeting with a request for a two minute summary of each product. Do so and let both present but not discuss. Very firmly limit time here.
Summarize, using “this is what I heard” as your pattern. If possible, use a side by side layout which lists key features and weaknesses on both sides. Excel on the laptop for display on the smart board works well here.
Then allow a limited time for each side to question the other by laying out areas where points are unclear. Limit discussion of the points (aka answers) until the whole task of identifying issues is done.
Summarize again, still using “this is what I heard” as your pattern.
Next, look for places where the two sides conflict, complement, blend, or are redundant. Expand feature lists and conflict areas as necessary, but don’t get caught in extended discussion (yet).
Identify areas that seem to favor merging or separating products.
Order the points. Use your own impression of priority, allocating a brief time for adjusting priority by the group.
Parse out the remaining time for discussion, leaving a block for defining the next step at the end.
The objectives are
> to get issues visible to everyone;
> to resolve points where an item is understood differently by the sides;
> to visibly find points of blending and conflicts;
> to set the next agenda for resolution after research.
This may not fit your needs at all, of course. It’s a start, though, and works with the neutral driver concept. Adapt freely.
Whaddaya think?
The second comment, that was deleted, was an inadvertent duplicate of an "Akakie" comment. Since he gets plenty of airtime as it is, there seems no reason he should get duplicates.
Your suggestions are good ones, although I think in this case they don't quite apply. You see, I'm already a member of one of the development teams and the primary contact on our team for the other team. A manager a couple levels up my organization's chain of command was having conversations with a manager a couple of levels of the other team's chain of command, they came to some kind of general agreement, then my guy set up the meeting. Neither of the upper-level guys came to the meeting. All-in-all, not a recipe for success.
Since I wrote the post a couple days ago, the meeting taking place "next week" was actually today. In the end, it went well, as you can see from this email I received from a coworker:
"Great job running the meeting! You navigated the [name] team well. There were a couple times where I would have lost my cool and you kept things on an even keel. Your summary below is much more PC as well and can go to both sides (mine was intended for our team only)."
Post a Comment