Problem Resolution Meeting

One of the more common meeting types that I deal with is the Problem Resolution Meeting (aka [Fly] Swat meeting). This meeting is intended to focus a small group of people into resolving a specific problem set. Unlike other meetings, I avoid a bit of the formalities and do not capture minutes or provide an agenda.

This meeting is usually triggered when I notice a long e-mail conversation chain on my Outlook where the To list keeps on growing. Seeing something like that usually indicates to me that there’s a problem that needs to be resolved. Fortunately, it falls into my scope of work to resolve these issues (sometimes I have to ask my direct manager who may know the “political climate” more than I do for permission before I take the reigns).

The way I tend to run this meeting is to choose only a select few people that can help me solve the problem. They tend to be the leads or peers of people that do the work rather than the people who actually perform the work. I also avoid anyone in their report-to chain when I am running the meeting. By limiting the number of people, it allows for a more close knit forum where people can shout out ideas to help resolve the problem.

The reason why I avoid the actual people who do the work is to allow them to perform the work separate from the problem solving portion. It allows me to get the peer/lead to forward the work to the worker and let them get back into the conversation quickly. Sometimes it is the actual worker, which is also good, but there may be a “pause” on the meeting while things are being resolved.

The meetings are usually scheduled at 30 minutes. This forces people to do away with formalities, and just focus on resolving the problem set at hand. Sometimes this goes past 30 minutes, and I try to have a time check at minute 25 to see if people can still go on or if they have other obligations. In most scenarios their report-to chains have already asked them to focus on the problem anyway.

In my intro, I had noted that the meeting is intended to resolve a problem set, rather than one specific problem. In many cases fixing problems tends to breed more problems. Think of it as hitting one land mine to the next. However, the good part of the meeting is we are still a focused group and we just keep on hacking things until they all start working.

I also noted that the meeting should only contain the people that can help us resolve the problem. So as soon as I realize a component is okay or not really relevant, I inform the person that he/she may leave the meeting so they can work on their other stuff (with a caveat that I may call them). I make it a habit of individually thanking them (usually via IM), but that is also to ensure that I can reach them via IM if needed so there is a bit of an ulterior motive [at least I am being honest about it].

The meetings tend to not include any of the report-to chains. The reason is the meeting already contains people who are supposed to do the work, and already has one coordinator (usually me) so there is no need for them to listen in. However, I do let the report-to chains that the meeting is going on and inform them that I will send them an update by certain times. This allows them to focus on other things because the immediate problem is already being handled and their presence won’t add much value when we are discussing low level issues (e.g. log files and stack traces).

I may invite the report-to chains to the meetings, but as optional. It isn’t because I want them there, but it is more that they know the meeting information (i.e. conference number, location and time) so they may forward it to other people who we may need in the meeting that we couldn’t reach within the group. Of course I would let them know that I may need such a support and may call upon them at that time.

In order to keep things focused and to respect other people’s time, I terminate the meeting once we reach an impasse. Usually this occurs when we realize that we may need support from other groups that are not involved in the call at which case I will call upon the report-to chains to provide us the support so we may continue. Nothing is worst than being idle in a meeting.

As I noted before, I always have a status report to send periodically (every hour or so). This may seem overkill, but it allows everyone in the group, their report-to chains and most importantly myself to have things level set. The status reports are sent to the whole gamut of people that were involved as an FYI.

In the end I and most of my colleagues find that the way I run the meeting tends to get things done and with less stress and boredom for those people involved.