Debugging your Consultants!

I caught up with Daz and Mitch yesterday for a quick coffee and chin wag while both Readifians were illin' in Melbourne, and we got onto the topic of training and getting the best out of people. We started chatting about the concept of chunking (we all have had a stab at what chunking meant to us) again, and I recalled a technique I used to use which I call consultant debugging.

Now, to create some context. Everyone has met those consultants who are at the top of the game. You know the ones, completely unflappable, always impeccably prepared, rapidly cognizant, surgically articulate but not terse. The ones who are so deft at their trade that they compel you to engage them just to experience their style time and time again. Well, when I started working as a consultant, I strived to be one of those consultants, and over the years I realized that there was one technique that prevailed among all; consultant debugging!

It's a simple concept, but very powerful. Essentially, the basis for all consulting is interaction. But it's not just the basic interactions we experienced day to day, it's an interaction known as consultation, that is, I require expert advice and guidance to achieve an outcome. So the person (or the consultant) who is on the "providing" side of the equation should be an expert not at a particular field per se, but more, an expert in problem decomposition and response. So when dealing with a customer, a consultant should always employ a problem decomposition strategy, to ensure they elicit all the right information, mask all the misinformation, and are able to quickly and accurately formulate a response to the customer. Hmmm, kind of sounds like a chess game ;)

So before you ever walk into a customer engagement, you should start a flow chart. For example (just as an illustration):

Now the idea is, you walk through this tree, and at each state change, you determine a tactic, or a move, that will help you reach your desired outcome, which should be an unreal customer experience. Now, the first time you think about this, you will come up with some ideas, but nothing proves like proof! So when you walk into that meeting, and some things happen that weren't in your plan, you're going to deal with them in-step. Key thing is to remember what you did, and how that affected the outcome. For example, when you arrived late, instead of "Rushing" or "Rescheduling", the customer was irate and told you to leave and never contact them again. You apologized, were honest about why you were late and they then agreed to "Reschedule". Capturing these unplanned events is crucial to constantly refactoring your program (think like a computer), and storing these moves in your mind will help you react without thinking when in the moment, just like chess players do. Eventually, you will have "trained" yourself to react to a myriad of events during a consult that are proven and tested to help you get to your desired state or outcome...the customer engaging your services. You can also apply the chunking strategy, and rather than store the whole plan, store parts that are related, so for example, train yourself to exclude one half of the tree as from the first step. If you're on time for example, you never have to consider any strategy steps on the "Late" branch, so exclude it straight away! You may have duplicate steps, and I'd avoid linking to other branches, as that leads to complexity, so just duplicate the steps that need to be in other parts of your tree.

Now, this applies to anything right? Trying to get a promotion, trying to get a new computer, trying to get extra chips with your lunch! It's all about preparing, training, practicing, refining, and so on. What you end up doing is building on your experience and technique over time, with a clear program which you can debug at any time!