The Business Gnome

The following is the original and the rewrite can be found by clicking here.

It's been a little over 90 days since I have been blogging under the unicorn banner of GPEStratagem and I wanted to quickly say, "Thank you for reading". I also wanted to take a moment to ground us as to what I story tell about - Specifically, I am interested in out of the box thinking as well as creative problem solving, particularly in the areas of sales and marketing; this of course can run the gamut including situation analysis, planning, problem solving, leadership, execution, process improvement, organizational behaviour and of course the customer. With all of this said, it is probably time to mention the rarely seen, but very much believed in, Business Gnome.

I've heard the business Gnome looks like this...

A very dear friend of mine, who I hope is finding great fun and adventure at the moment, introduced me to the Business Gnome a number of years back. For those of you who are not familiar with the Business Gnome, it is a genus of "mystical individuals" who get things done when people don't think of it, assume it'll will get done, don't want to do it, or don't know how. The Business Gnome falls into a number of different species, such as the "Technology" Gnome, the "Marketing" Gnome, the "Clean up your mess" Gnome (which has a domesticated cousin), and so on. Business Gnomes, like "tribbles" (yes a Star Trek reference), are cute and cuddly, but if they get into the machinery they will totally mess up effective execution and most definitely impact your customer's experience.

Let me offer you an example of what I am talking about - A small company was sponsoring an event which involved developing a process to sell the event tickets online and went live with it. It turned out when a customer went to order a ticket, the only option available in the drop down menu was zero. After that was fixed, it became apparent that there was no electronic ticket that was actually sent to the person who had ordered... just a receipt indicating that their credit card had been charged. In all of this, it is obvious that someone looked to the "Technology" Gnome to ensure it all worked when they set up the process. It was a good thing the company was so customer oriented as they caught this with the first order and fixed the situation. They went on to have an amazing event and the Technology Gnome was conspicuously absent. 

As you can appreciate there are two camps regarding the existence of the Business Gnome and I don't want to spend time debating their actual existence but instead spend a little time on the "people and company cultures" that do believe in them... or at least act as if they do. 

People (and cultures) that don't take the customer's perspective in what they do are big believers in the Business Gnome, and look to them to ensure that all of their initiatives and processes work smoothly. To this point let's use the situation with the event tickets above - If, before they went live with the ordering system, someone had said, "Let me pretend I am a customer and see how this works", they would have discovered very quickly that they had some "gaps" in their process, and ultimately in the customer experience. Those who think like customers don't believe in Gnomes.

There also seems to be a correlation with people not knowing the systems and processes that they use and their belief in Gnomes. Many a time I have seen a brilliant idea come crashing into reality because of the limitations of the systems and processes that are available... somewhere, somehow, someone must have had faith in the "Operations" Gnome to make it all work. As an extension to this, there are people who are miscast for the task ahead but "do it anyway", without soliciting help and the resources needed to make it happen. They must be big believers in the "Hope and a Prayer" Gnome. 

And lastly, the biggest playground for Business Gnomes that I have seen is where there is a culture of assumption... Assuming it will get done, assuming the resources are there, assuming the skill sets are in place, assuming the customer thinks like you, assuming there is someone to pick up after you, assuming the system will do what you want it to do, assuming your pilot project will scale - Hopefully you get my drift, and if you find too much assumption going on, you most likely have a deep seeded belief in Gnomes. 

Of course, encouraging Personal Leadership, Ownership and an understanding that everything is connected can create a culture of accountability... dispelling the mythology of the Business Gnome. 

Let me know if you have seen a Gnome, and do remember that "Car Key" Gnomes are very real.

gpe

Thank you...

This post, although short, is very special as it is dedicated to the 10 people who currently subscript to my bi-weekly blog. I wanted to take the time to thank you for subscribing; it's not just that though, I also want to thank you for your feedback, your editing, your interest, the "retweets", your ideas and your comments.

In the three months (as of today) that I have been blogging, I have discovered a number of things:

1. I really, truly, like writing... wait... it's more like story telling I think.
2. The process I go through is the same, blog after blog... I start off with an idea, then words on the page which lead to this emotional roller coaster: "I like this".... "I hate this"..."grammar is stupid (and so is spelling)", and ultimately "this is pretty good" - SEND.
3. I don't know why people are afraid of punctuation? The semi colon is so much fun. Use as you see fit.
4. It seems I have an opinion on many things.

I am not "pushing" this post out to any other social media, so in a practical sense you are currently the only ones who will read these words, and for that I am very grateful. I want to share this with you with great appreciation.

"I hope you will have a wonderful year, that you'll dream dangerously and outrageously, that you'll make something that didn't exist before you made it, that you will be loved and that you will be liked, and that you will have people to love and like in return. And, most importantly (because I think there should be more kindness ad more wisdom in the world right now), that you will, when you need to be, be wise, and that you will always be kind."

Neil Gaiman wrote this, who if you do not know, is the husband of Amanda Palmer... and we all know the big crush I have on her.

As they say, "all writers start with zero readers". Thank you for being my first ten.

gpe

Execution.... the third in a series of thoughts

The following is the original and the rewrite can be found by clicking here.

I had promised I would talk about the fun you can have with process mapping and I think the best segue into this would be to start with "Meeting attendance auto-Pilot", or for those who love acronyms, MaaP*. 

A lifetime ago, in another world, I found myself in a meeting listening to a marketing manager review a promotional initiative that was in "pilot phase". It was here that I slipped into MaaP. I'll take a moment to define it for those not familiar with it - MaaP is the ability to be aware of everything happening in a meeting while mentally tending to the many other things you would be doing if not for the meeting. I should also point out this is not an aspect of disrespect but more a necessity for survival in some companies. I suspect it's comparable to an out of body experience. 

All of a sudden my MaaP drops out of warp drive and I find myself saying, "run that by me again?" It is here that I'm retold how the promotional fulfillment component of the "cool smartphone app promotion" is fulfilled automatically in one case, but in the other instance the fulfillment needs to be done through the sales force. There is some discussion with regard to using the sales force for promotional fulfillment and how it is a bad idea... it distracts the sales force and increases the exposure to having a disappointed customer. The marketing manager points out that it is a "very cool app" and there were few examples of the need for the sales force in the pilot. To that it was pointed out that the pilot would not scale in its current form. The meeting continued and I think I may have slipped back into MaaP.

Example of a simple process map (some get very complicated)

Let's fast forward three months after my MaaP experience... by then, that "app promotion" had rolled out into the market and my role had changed where I was now much closer to the impending storm of "a pissed off sales force and disgruntled customers". As I got into the situation it became clear few people were aware of, or even understood the impending "problem". It was time to develop a process map as to how this promotion worked - Not a bad segue eh?**.

So what is a Process Map? -  A process map is essentially a breakdown of a process to determine how it flows and, ultimately, how effective it is. Those who complete process mapping look closely at elements such as the structure of a system and the flow of communication within the system. It consists of circles, boxes, diamonds and arrows representing the flow. (see diagram)

• The circle (oval, or rounded box) represents the start or end of the process
• The square represents a specific activity as part of the process
• The diamond represents a decision making point (yes or no)
• The arrow represents the flow and the connectors from activity to activity through the decision points.

Here is why I like the process map: 1) it forces you to understand your process and how you do what you do, 2) it is a visual representative, so you can literally see what you are working with and by extension makes communication easier, 3) it makes it much easier to identify problems and gaps in your process and 4) it helps determine optimization, correction and execution.

So now back to the process map of the promotion... well it was so complicated it looked like a "circuit board"; so much so when I was reviewing it with someone they simply looked at me and said, "you've got to be kidding". In the end, this process map made it easier to communicate the situation and illustrate it's impact on the customer, as well as internally. It ultimately led  to process improvement, that, although not perfect, alleviated the immediate issues.

As I look back at this situation and what came out of it, a few things resonate with me still - 

• Development of a process map in the beginning, as well as a better understanding of the systems that you work with***, probably would have driven better execution.
• Smartphone Apps are not a silver bullet.
• No matter how much someone tries to convince themselves that there is not a problem, there is.

There is a great science to process mapping, as well as its close cousin functional excellence, and I have learned over the years that is it is an excellent tool to help you optimize all things involved with execution.

I hope you are finding this series informative, as well as maybe a little entertaining. Let me know.

gpe

* I will be the first to admit that this could just be me, as at the end of the day I have the attention span of a small insect.

** Remember I am Canadian.

*** Understanding the systems that you have available is imperative for optimized execution. It makes me nuts when people try to work outside the functionality of the system at their disposal and then blame the system for any shortcoming. I mean, I wish I had a "matter transfer device" to get around, but I don't so until then I will work with the airline industry.