COMMUNICATION SKILLS
Hedge 175: Mike B on Personal Superpowers
When the economy starts contracting, career advisors start talking about the importance of “soft skills.” What are “soft skills,” exactly—and why are they “soft?” Mike Bushong joins Tom Amman and Russ White to talk about why these skills are important, why they are not “soft,” and how we should talk about people skills instead. They are superpowers,” and there isn’t anything “soft” about them.
The Hedge 78: Mike Bushong and Radical Candor
Communication is one of those soft skills so often cited as a key to success—but what does effective communication entail? Mike Bushong joins Eyvonne Sharp and Russ White on the Hedge to discuss radical candor, and the importance of giving and taking honest feedback to relationships and business.
The Hedge 17: Michael Natkin and Strong Opinions Loosely Held
According to Michael Natkin, “in the tech industry, with our motto of “strong opinions, loosely held” (also known as “strong opinions, weakly held”), we’ve glorified overconfidence.” Michael joins Tom Ammon and Russ White to discuss the culture of overconfidence, and how it impacts the field of information technology.
The Hedge 11: Roland Dobbins on Working Remotely
I failed to include the right categories the first time, so this didn’t make it into the podcast catcher feeds correctly…
Network engineering and operations are both “mental work” that can largely be done remotely—but working remote is not only great in many ways, it is also often fraught with problems. In this episode of the Hedge, Roland Dobbins joins Tom and Russ to discuss the ins and outs of working remote, including some strategies we have found effective at removing many of the negative aspects.
Explain-a-holic (Communicate Clearly)
But just a couple of days ago, I was talking to someone about managing expectations in the IT world. How do you convince someone else to buy into a project? How do you get them to back your idea, rather than inventing their own? While the question itself is interesting, I’m going to leave my thoughts on it to another post.
What I realized, halfway through answering the question, was that I was sucking up a lot of time talking about things that probably didn’t matter. I was spending time talking about the problems of getting people to own the problem, or make them believe they’d invented the solution, and specific projects I’d been involved in where we could never convince a wide group of people to buy into our ideas and solutions.
At some point, I’m certain I sounded like this snippet from a recent email —
Like if I asked, “what is 1+1?” he might say, “one takes 1, and adds 1 to it, and you get the next integer, which is really quite interesting, because you can do this over and over again, and never get the same answer, which is a bit like…”
There are, generally speaking, two kinds of engineers in the world. Those who know how to talk to people, and those who don’t. You should really learn to be the first kind, of course. But the problem with engineers is once we learn to talk, we have a hard time shutting up. It’s all too easy for an engineer to move from the quiet kid in the corner who never says anything to the boisterous person who talks about everything without explaining anything.
In other words, it’s all too easy to become an explain-a-holic.
The probable cause of this tendency is two fold. First, as engineers, much of our living depends on knowing a lot about a lot of things. It’s all too easy to get wrapped up in the resume padding game, wanting to make certain your audience really knows just how much of a geek you are, and how many little areas of technology you know about. Second, as engineers, it’s easy to get lost in the details of how something works rather than why. Engineering has a fix this now mindset, often making it difficult to listen, or to limit ourselves to the immediate question.
How can you solve this (see — engineering!)?
Listen to the question. You need to listen to what is being asked, rather than for things you know how to answer. A lot of the explain-a-holic tendency is simply putting fluff around the words “I don’t know this, but I do know that.” A little humility (I know that’s hard, because most geeks don’t excel at humility).
Give brief answers. Listen to what you’re saying when you answer. One reason I like to blog is because I must keep my posts around 500-1000 words — a challenge, since I’m used to writing much longer pieces of text.
Minimize the example. A common rule of thumb for slides is, “if you can’t explain it with five routers, you don’t understand it well enough.” There is a good illustration or example for every principle in the world — and it’s always small enough that it’s easier to understand than the concept itself. In the engineering world, we love complex examples that develop every potential case, including small corner cases that are only encountered once every hundred years. No example is going to “run on all four feet.” They’ll all be just partial explanations. But try to extract the principle in the simplest example possible.
It’s not about you. You’re not trying to make your listener love (or like) you. You’re just trying to explain a simple idea. It’s useful to keep the explanation entertaining, so it’s easier to remember, but it’s not about you.
Of course, I’m writing this post for myself as much as I am for you — these are ideas we all need to learn to live by.
Don’t be an explain-a-holic. Communicate clearly.
Eschew Obfuscation (Communicate Clearly)
Many years ago, I worked for a manager who had two signs on his desk. The first was a pencil with the words, “Pencil 2.0” printed above them. The rest of the sign went on to explain how the pencil had undo (the eraser), was renewable (it can be sharpened), etc. The second sign was simpler, just two black words printed across a white background.
Eschew Obfuscation
Being just out of the US Air Force, and not having quite the vocabulary I should have (have I ever told you that reading is the key to having a great vocabulary?), I didn’t really understand the point. Now I do. Okay, to make it more obvious, from the Collins English Dictionary, 8th edition:
eschew: tr to keep clear of or abstain from (something disliked, injurious, etc.); shun; avoid
obfuscation: the act or an instance of making something obscure, dark, or difficult to understand
Now do you see? Avoid using language people can’t understand. Far too often, in the technical world, we use abbreviations, acronyms, and all sorts of cute nonsense to say things. We pepper our language with shorthands and inside jokes (squirrel!). While this sometimes helps communication, sometimes it’s a form of social stenography — a way of keeping “outsiders” from understanding. And sometimes it’s just a way of saying, “I really don’t know what I’m talking about, but you should listen, because I know all the right buzzwords.” As we always used to say —
The modular capabilities support of this system is driven by the dynamic parameters array and functional systems implementation of the integrated performance environment.
Yes, I’ve been around enough to actually own an original Gerry Cohen Dial-A-Buzzword. There’s a digital version here, if you’re so inclined — I used to have a computer specific one up in javascript, but I’ve not updated it in a long time, so I finally took it down.
What is the point of my little rant about buzzword bingo and technical gobbledygook? Is it that we need to stop using buzzwords? That we’ve all been silently assimilated into marketing without realizing it? That we all sound like idiots when we talk? None of the above. Rather, my point is simply this:
If your audience doesn’t understand you, it’s your fault.
Whether we’re writing or speaking, presenting or whiteboarding, it’s far too easy just to call someone clueless when they don’t understand. This is a bad habit we engineers need to break — we need to learn to communicate clearly, no matter what we’re communicating. Whether or not we use engtalk when we’re working with other engineers we’re certain will understand us, we need to learn to take responsibility for being understood.
Specific suggestions?
Slow down. I don’t know about you, but I talk too darn fast. Being born and raised in the southeastern United States doesn’t make it any better — “y’all” really fast is even harder to understand than “youse guys.”
Spell it out. If someone doesn’t know an abbreviation, don’t treat them like an idiot — spell it out. And if you don’t know some abbreviation, don’t be afraid to ask.
Abstract to the right level. Sometimes people just aren’t going to understand at the depth you know how to explain. Learn how to find multiple levels of abstraction, examples, analogs, and illustrations to help them understand.
Use images. Even if you just have words, use those words to paint a picture. Make your drawings clear and understandable. Don’t draw things you don’t need to explain the problem, solution, or technology. If it takes more than five routers to illustrate, then you need to rethink how you’re explaining it.
But finally, mostly, and most importantly — take responsibility for being understood. Trust me, you’ll be a better engineer if you do.
Why Your Presentation Stinks (Part 2)
Last time, we talked a little about making certain your presentation has a point — or a porpoise, as the case might be. This time I want to talk about a few other common mistakes I see network engineers make when building presentations, and actually presenting them.
First, you put too much text on your slides. I know you’re afraid you’re not going to remember everything you want to say, but that’s no excuse to have a 500 word essay on every slide. The bullet points on a slide are supposed to be just that — bullet points. They’re supposed to remind you of what you mean to say at this point in the presentation, not to be the actual words you’re planning on saying.
Okay, I understand we’re running head in to another problem here — what about folks who print my presentation out and take it home to read it later? That’s what hidden slides are for. Put all the text you really want to put into a slide on a hidden slide just after the slide itself. Then pull out just enough words for you to remember what’s on the hidden slide when you’re doing the presentation. If you really need the text, it’s still there, and it’s there for folks reading the presentation afterwards.
But the audience should be listening to you, not reading your slides.
Second, your network diagrams are too complex. Seriously, if you can’t explain a point with less than six or seven routers, rethink what you’re explaining. I know network diagrams are hard to draw, so it’s really tempting to put a single diagram together and use it to illustrate everything from neighbor formation to flooding domain boundaries in OSPF on every slide in the entire presentation. But — trust on this — your audience is dazed and confused enough. You don’t need to confuse them with a huge network diagram.
There’s another point to this, as well — when we were developing the CCDE, one thing we ran in to is a heavy load of cognitive dissonance. When someone spends time seriously thinking about a principle or concept, they will continue thinking about that same principle or concept when they see the same illustration again. People have a hard time thinking about neighbor formation between two little routers drawn into the corner of a huge diagram, and then shifting gears to think about flooding domain boundaries explained using one of those two same routers in the same diagram. In the end, we had to provide more “mental separation” between the different sections on the practical to relieve some of this problem.
Whether or not you want to believe it, your audience is experiencing this same sort of problem in your presentation. Stop using the same network diagram to explain everything.
Third, you’re not leaving enough white space around your images and text. We engineers seem to be deathly afraid of white space, like rock concerts are afraid of quiet. We’re somehow afraid that our audience is going to slip into those little spaces and get lost, like Dr. Who slipping into the TARDIS, or some such.
On the contrary, white space is critical to our ability to process information. White space provides separation between concepts like an ABR provides space between flooding domains. Open MS Word, create a new document with two columns, and set the gutter between the columns to .001. Copy and paste a huge amount of text in there, and try to read it.
That’s what your presentation looks like.
That’s it for my initial tips on building a good presentation. As I run across other tips, or graphic design books I think are good segues into the world of building solid presentations, I’ll post them here.