Skip to main content

Decisions: Cut and Dry?

Is any decision ever an easy one to make? I suppose that some decisions are, but it truly depends on the topic of discussion. For example, when my wife and I recently decided to go to Ruth Cris for Valentine's Day dinner, neither of us spent more than 0.13259876 seconds to come up with a collective "yes" on the matter.

Other decisions, especially business ones, are not so easy. Rarely does a manager have the luxury of deciding something that does not have ramifications beyond the five minutes immediately following the decision (save for where to go for lunch perhaps). Instead, they are frequently called upon to determine the direction that their ship will travel for the next week, month, or even year.

Consider the decision of hiring someone. Susan Docherty who leads the sales, service and marketing for GM's U.S. operations recently described her philosophy around the hiring process in an interview by the New York Times. There's no need to discuss it in detail, but I will mention one thing that is relevant to everyone reading this: such a decision with its potentially far reaching consequences is not taken lightly. In fact, she puts quite a bit of effort into researching potential candidates and inspecting them in person to determine the degree of fit within her team.

I claim that this is the hallmark of a good decision maker. Don't take what I'm saying to extremes, however. While it is certainly possible to over analyze things to the point of paralyzing oneself, it is also possible to do quite the opposite: make a decision off the cuff based solely on one's gut reaction; a recipe for disaster. ("Fools rush in where angels fear to tread," and all that nonsense is applicable here.)

What Ms. Docherty has done is develop a process to do enough analysis to support her when she makes the decision, but still avoids making the decision based solely on what information is available from other sources. In other words, she doesn't depend on the resume alone or even the input of others. Instead, all of these things are rolled up and kneaded like bread dough along with her own impressions she forms after meeting the person.

Once a decision has been made, then the crucial part of selling the decision to others begins. Specifically, any decision on policy, process, etc. will need the support of others - even subordinates - in order to be successful. Otherwise, you will have empty shells of people simply going through the motions, only trying to fulfill the letter of the law instead of the spirit of it. Selling decisions like these takes a certain degree of finesse (not unlike selling goods or services to clients of your company), and this should not be understated.

For example, another interview by the New York Times with George Cloutier yielded some very interesting and even good ideas about how to run a small- to mid-sized business. Yet the means by which he communicated these to the report came off as crass, arrogant, and even obnoxious. Do his ideas have merit? Yes. Would I be as willing as a small business owner to implement his ideas? Perhaps, but not without a lot more convincing as to why his ideas are better than my own. As it stands now, he comes off as someone looking down his nose at those his company serves, and no one likes hubris regardless of the shape or form it comes in.

Popular posts from this blog

"Ni jiang yi yang de hua ma?"

Last week, I wrote about the necessity of having a clear message . Because this topic is so important I decided to follow-up with another entry on this general subject. This week we will approach it from another angle. (For the curious, the title says " Do you speak the same language? " in pinyin, which is a transliterated Mandarin Chinese.) Recently, a good friend of mine (who is Chinese, ironically) and I were playing pool. He had to bank the 8-ball in the pocket to win the game, and since it was an informal game and bank shots are my area of expertise, he asked me for advice. I told him, "you just need to strike the cue ball with medium speed so that it hits the 8-ball right in the middle." He didn't believe me so we marked the positions of the balls, and then he took his shot only to watch the 8-ball sail past the pocket. "A-ha!" he exclaimed. "I told you it wasn't that easy." But when we reset the positions and I made an attemp

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While that

Is No/Low-Code the Key to IT Nirvana?

 Unless you've had your head in the sand for the past year or so, you've seen the phrases low-code  and no-code  bandied about quite frequently everywhere you look.  You've probably wondered if this is something new that's here to stay or just a "flash in the pan."  Although the terms have been in the fore of the IT trade publications recently, Low Code Development Platforms (LCDP) (and the corresponding No Code Development Platforms) have been in existence since 2011.  Their roots can be traced to the 90's with 4th generation programming languages and GUI-assisted programming paradigms, e.g. IBM VisualAge for Basic, which was discontinued in 1998. For those of you who aren't familiar with either, the premise is that these platforms allow someone to quickly build applications using a WYSIWYG interface and a "click and configure" paradigm to Isn't this the source code to Roblox? rapidly build full applications with little or no coding requ