There’s a fine art to running a productive meeting, keeping the discussion focused and scoping things tight to meet your scheduled finish time. Today’s consulting lines post is about keeping people happy while still finishing meetings on time.
Let’s join a troubleshooting session where I’ve been brought in to help a client whose AlwaysOn Availability Groups are failing over randomly in the middle of the day.
The Conversation:
Me: “According to the network control panel, this server has two Ethernet ports, but only one of them is plugged in?”
Sarah the Sysadmin: “Yeah. All our physical servers are set up that way, and I’m not happy about it either. We’re going to be virtualizing these servers early next year, and I’ve got a preliminary plan for the networking switches that I can show you. I can just present one network card to the guest and do the teaming at the host layer, right?”
Me: “That’s a great question. I’m going to set up a section of the whiteboard over here called the Parking Lot, and I’m going to write that down.”
What That Line Does
It conveys that the question is indeed a good one, and you’re qualified to answer it, but that the answer is going to take more than a minute or two.
It also sets up a normal protocol that can help you through the rest of the meeting – and heck, even the client relationship. One of my long-term clients got so trained that when I walked into their conference room, they’d already white boarded out the day’s agenda ahead of time – and set up a parking lot with a few items!
If you’re working remotely, you can use a shared Google Drive document to track the meeting’s agenda, notes, resources, and parking lot. (Just be careful with the Google permissions – those get kinda tricky when you’re working with multiple clients.)
What Happens Next
Sarah: “But this will only take a minute – ”
Me: “Are you willing to virtualize those servers this weekend?”
Sarah: “Oh definitely not, we have to buy the hosts and – ”
Me: “Can we just leave the failover problems as-is, and wait for the virtualization replacements?”
Mark the Manager: “No, we need the failovers fixed now, like yesterday.”
Me: “OK, so here’s the deal. I definitely want to help you configure the virtualization project, and the answer involves sketching out whether you’re using iSCSI or not. My contract for today’s engagement depends on me solving this failover problem, so I kinda gotta focus on that for now. If I don’t fix this, the executives won’t pay my bill, and my wife is getting tired of ketchup sandwiches, ha ha ho ho. So let’s put this in the parking lot, and we can talk about it as soon as we’ve got the root cause of the failover identified. Is that fair?”
For more meeting tactics, check out my consulting lines.
8 Comments. Leave new
Oh my… Brent this is a GREAT idea… wish I had thought of it during the work I did for HP, for their migration project back in 2010. That project had a LOT of meetings where my answer was .. “Yes and No”, because the questions depended on too many variables to discuss … in the time frame for the current meeting.
Can you please share root cause for the random failover?
Ovidiu – this is a fictional example designed to tell a story. (I have to use made-up examples or else my clients might think I’m telling THEIR stories online, and that wouldn’t be good!)
Thank you very much for the answer..it does make a lot of sense
Maybe you could have told us the answer and added ‘I’ve seen this at hundreds of clients’? Then not only do they not think you’re telling stories out of school, possibly they feel less bad about having a problem that affects a lot of people…
Would your approach be different if it is a boss/stakeholder/manager/exec/C-level doing the tangenting and doesn’t understand enough about the problem space or technologies involved? I know it’s not the same thing but I struggle with this daily as an underling. (I.e. they don’t accept that there isn’t a one minute answer to the tangent).
Also, what happens to the parking lot? Do you end up addressing (the high value) things later on or adding them to the team’s backlog/pipeline? If not I imagine the list grows quickly and gets a life of it’s own.
Non-contractor – about the parking lot – we wait until the end of the day, and if the problems have been solved, we take time to walk through the parking lot. If we don’t have time, I ask if they’d like to set up a followup engagement to talk through the parking lot. At that point, armed with the list of things in the parking lot, management has a good idea of where to focus their team’s training next. For example, I can say, “It looks like we had a lot of questions around indexing. Here’s where I’d recommend going next – hit this index training video, or go to this training class, or read this book.” Those are more cost-effective options than onsite consulting.
About the manager – as a consultant, I’m kinda lucky because the boss/stakeholder/manager understands that I’m being paid by the hour, so there’s a literal cost to their questions. If their technical staff *do* understand the concept, then I can point at a senior member of the technical staff and say, “During one of the breaks or over lunch, would you mind having a discussion with boss/stakeholder/manager about this concept to bring them up to speed?” If the technical staff *don’t* understand the concept, then it just goes in the parking lot like any other question.
I love good managers because they aren’t afraid to ask a dumb question aloud, whereas their technical staff don’t want to show their ignorance. I’ve had so many great discussions after a manager asked, “Can you explain that to me?” when I can tell their staff are eagerly interested in my explanation too.
Seriously? What is wrong with Ketchup sandwiches.