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 second 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.