One area where I feel I’ve learned and grown in my career is achieving a much clearer understanding on how to communicate with upper management. Most advice along these lines tends towards simply warning against overuse of technobabble, and I can’t disagree with that. But there’s a lot more to successful communication than simply that, and I’d like to describe here a few ways to avoid the pitfalls that I’ve seen IT people (including myself) fall into in these situations. None of these ideas is especially new or difficult, but they don’t always seem to come intuitively to IT folks.
When presenting a problem and/or proposal to upper management, keep in mind the following:
- Outline the problem as clearly and succinctly as you can, with appropriate quantitative facts (metrics) and business-related impacts wherever possible, to demonstrate why you’re bringing it to their attention.
- Do it in writing, not just verbally. If you’re not as comfortable writing as “talking through” an issue, then you need to get comfortable. See my previous post on the importance of writing.
- Be succinct. Keeping to one page is a great goal for the bulk of the presentation. Anything longer than 3 or 4 pages will simply not get read.
- Avoid hyperbole/overreaction. Technology folks are unfortunately known for overstating things. It will help neither your cause nor your career if you come across as Chicken Little or the Boy Who Cried Wolf, let alone as Howard Beale.
- Marshal your facts carefully. Facts beat strong opinions every single time. Don’t make your presentation just a collection of strongly stated opinions. Present the facts as neutrally as possible, with relatively little advocacy besides your recommendation.
- Which facts matter most to executives? Mostly two major categories: direct financial impacts of the solution you’re presenting, and business/customer impacts. What facts matter least? Any notion of a technology being “better” or “newer”, except when you can translate that betterness into a form of measurable financial, business, or customer-related impact.
- Offer 2-3 alternatives as solutions, discussing the pros and cons of each, and then present your recommendation and your reasoning. Do not present a one-sided pitch that indicates that only one solution is remotely fathomable. Even when that’s the case.
- Provide background material, but in an appendix. There’s definitely some value to having meat and volume (“thunk factor”) to back up your statements and recommendation, but you don’t want to include that morass of detail in the body of your presentation.
- Don’t keep selling. Whenever possible, let your audience draw its conclusions, rather than having you continue to advocate.
- Always answer the obvious and ubiquitous questions they’re going to ask, before they ask them. Here are the main ones you’ll hear again and again:
- “How much will this cost?”
- “When can we have it?”
- “What else will get pushed aside if we do this?”
Even if you follow all this advice, in the end we all need to recognize that communicating the full impact and flavor of technical matters can be difficult and murky, even with the best of intentions and the most adept skills. In short: people’s eyes tend to glaze over when confronting the detail they truly need to understand in order to help make a valid decision. IT people, faced with that lack of interest and comprehension, can often err on the side of throwing up their hands, avoiding communicating altogether, and simply taking independent action. I don’t recommend that. Turning around the famous declaration from War Games, “the only losing move is not to play the game.”
Lagniappe:
At times, you may need to communicate the nuances of a technical situation obliquely and through creative use of metaphor, rather than through mind-numbing, technobabble-laden directness.
At the early age of 13, I learned that some things were best expressed in parables, especially if they were difficult to express or comprehend. To that point, I read a fascinating anecdote back then that reverberates in my mind decades later. It came from page 49 of a slender red volume of mathematical and scientific anecdotes (yes, I was a strange child), called The Other Side of the Equation, by Howard W. Eves, (c) 1971, Prindle, Weber & Schmidt. This book is now available as part of a larger volume that includes material by Mr. Eves.
Here’s the anecdote, and in the spirit of my advice above, I’ll let it speak for itself:
Einstein and his blind friend
Not long after Einstein’s arrival in Princeton he was invited, by the wife of one of the professors of mathematics at Princeton, to be guest of honor at a tea. Reluctantly, Einstein consented. After the tea had progressed for a time, the excited hostess, thrilled to have such an eminent guest of honor, fluttered out into the center of activity and with raised arms silenced the group. Bubbling out some words expressing her thrill and pleasure, she turned to Einstein and said: “I wonder, Dr. Einstein, if you would be so kind as to explain to my guests in a few words, just what is relativity theory?”
Without any hesitation Einstein rose to his feet and told a story. He said he was reminded of a walk he one day had with his blind friend. The day was hot and he turned to the blind friend and said, “I wish I had a glass of milk.”
“Glass,” replied the blind friend, “I know what that is. But what do you mean by milk?”
“Why, milk is a white fluid,” explained Einstein.
“Now fluid, I know what that is,” said the blind man. “but what is white?”
” Oh, white is the color of a swan’s feathers.”
” Feathers, now I know what they are, but what is a swan ?”
“A swan is a bird with a crooked neck.”
” Neck, I know what that is, but what do you mean by crooked ?”
At this point Einstein said he lost his patience. He seized his blind friend’s arm and pulled it straight. “There, now your arm is straight,” he said. Then he bent the blind friend’s arm at the elbow. “Now it is crooked.”
“Ah,” said the blind friend. “Now I know what milk is.”
And Einstein, at the tea, sat down.
My boss is a Harvard grad, and earned an MBA from a prestigious university. She knows little about tech, however, so my careful explanations (written or otherwise) about servers, operating systems and so on just make her eyes glaze over. I have had to be very careful to couch my explanations in easier to understand terms, just to get my points across.
I don’t know how it is in the corporate world, but some educators just refuse to learn anything about technology, or claim they are too busy. Instead, they would rather rely on the helpfulness of those in the know. Personally, I find it distressing that some administrators/managers seemingly resist learning about technology, which has become integral to how most organizations work. I would rather talk to someone with at least some passing familiarity with the subject. Such is not often the case, in my limited experience.
So we IT guys need to follow the advice here. We are the wizards who need to reveal the secrets behind our magicks.
Well, that’s EXACTLY how it is in the corporate world, I’m afraid. For the most part, anyway. I’ve certainly had my share of frustrations when dealing with that syndrome. Part of my point, though, is that I’ve seen it made worse by IT folks inappropriately presenting issues, as in “baffle ’em with baloney” (or worse). As I’ve written before, none of us took enough writing classes, by which I mean that writing takes time, blood, sweat, tears, to reach the audience.
Thanks for writing, wheatdogg! Good to hear perspective from the academic world on this.