Explaining technical things to non-technical people [closed]

Question

I often have to explain technical things and technical decisions to my extremely non technical manager and I'm pretty awful at it. What are good ways to essential dumb things down for the rest of the world who don't have a passion for programming?

Example questions I've been asked:

• Why are you using Django instead of Java (Didn't accept that it was cheaper either)
• Asking me to rephrase things in non technical words, my sentence was "Certain HTML tags are not allowed". How can I possibly dumb that down?
• Other stuff that makes perfect sense to me, but is just so basic I don't know how to explain it
• Why this, why that, why everything!

Also, how do I tell my manager to look the basic stuff up on Google, like "What is Pylons?"

Answer 1

I tend to use analogies. Take whatever the topic is, and think of something completely non-technical that they would understand, and explain it to them that way.

Best example I can think of offhand is if I need to explain object orientation, I'll explain it using a deck of cards. Or, when I was trying to explain the idea of wireless internet to my great aunt (who's never used a computer), I used cordless phones to explain it.

I've yet to come across any topic I can't dumb-down this way.

Update

I see this continues to get upvoted, so here's some of how I'd explain OOP with a deck of cards:

• A card is essentially a copy of the same object, a piece of stiff paper.
  • Each card has a set of properties (value [A-K], suit, face up/down), which may or may not be unique.
  • A card can be used in many different ways, without altering anything about the card (held in a hand, put in a deck, played on the field, etc.)
  • If you want to get into interfaces: A card must conform to certain standards, such as size and shape.
  • If you do something to one card, that doesn't affect any other card.
• A deck is a "container" object, which holds <= 52 card instances.
  • The deck can have various operations done on it, such as shuffle, show the top card, draw 5, etc.
  • The deck doesn't need to know or care about a card's value/suit, only that it is a card.
• A hand is another object, with a certain number of cards, and its own set of operations (play, add, remove, sort)

Answer 2

Things I Use

^{to great and not so great effect.}

• Analogies: When explaining a situation or a process it really works well if you can put it into terms that they will understand.
• Generic terms: Instead of saying HTML tags you could say code. If they follow up requesting an explanation it might be time for a brief summary of HTML and how it works. "Web pages are built out of blocks called "tags." If your browser doesn't support a specific tag the it won't be displayed correctly."
• Summaries and Overviews: Sometimes it works well to give a brief synopses prior to hitting them upside the head with technical jargon.
• Remove Jargon: Turn "The database isn't properly load balancing when hit by multiple requests from an IP subnet." into "The database is having trouble handling requests from certain people." If you might have to explain it, replace it with something else. If you have to explain database you're in trouble. "Place to store stuff" is my fallback.
• Visual Aids: Whiteboards rock. Use them to your advantage.
• Make them technical: Keeping managers, bosses, and coworkers in the loop helps. If the account manager is confused at meetings because everyone but them understands what's being said, it might make them want to read those emails they were CC'ed on. Take time when writing memos or emails to explain yourself thoroughly or point to references for explanation. Having someone figure out what HTML is on their own will probably be better then trying to cram it into them during an important meeting.

Answer 3

Once, long ago whilst still an undergraduate, I was asked to explain something over Sunday lunch - one of the most educational experiences I've ever had. The person asking the question was demonstrably not stupid - but had no background, the level of knowledge I assumed just wasn't there. I started to answer, got a blank look, changed down, still blank, changed down again, still blank... hmm... so I started the same way you start to build an application, with little blocks of explanation that you can build into something more substantial.

The key part of this lesson, for me, was (and is) just how much we assume (not just programmers, everyone) about other people's knowledge of our chosen speciality whereas in fact, even, you might reasonably assume that the majority of people know that 1 + 1 = 2 but after that it gets interesting.

So the first and most important thing to grasp is that people don't know and don't understand what you do - but they do understand what they do and when you're explaining stuff you therefore need to start simple and stay at an appropriate level for your audience.

In terms of specific techniques - I think that @Josh K has it pretty covered - and I'd emphasise that Analogies are an absolute winner.

One more thing - it may be, from time to time, acceptable to just write things off as "geek stuff" people don't always want full explanations of why and if you've previously demonstrated a willingness to explain and a capability to do so in an understandable manner then people will be inclined to trust you when you suggest that "complex technical reasons" apply or that ultimately you can achieve a particular result by "doing geek stuff" (or "programmer stuff" or whatever term works well in your environs).

Communicating technical things to a non technical audience (of one or more) is a skill, one that you can develop and one that you need.

Answer 4

Try to answer not in terms of the underlying technology, but in terms of the problem domain. "when a customer using firefox tries to place an order, his browser wont display the BUY IT button - that browser doesn't support the HTML tag we are using"

Often this is really the type of answer management wants. If he really does want to understand the low level details, the best bet is to make analogies to technology you know he does understand.

Answer 5

I try to find an analogy to something similar in the real world. Like, when I mentioned a stack and someone asked what that was:

"Well, you've got kids. Do they ever play with those little wooden blocks with letters on them?"

"Yeah."

"Ever see them make a big tower by stacking one block on top of another?"

"Yeah."

"OK, and when you've got a tower like that, it's only safe to touch the top of the tower, right? You can put another block on, or you can take the block on top off, but if you move anything underneath the top block, the whole thing's gonna fall down, right?"

Laughing. "Yep! They love to smash the tower and make them all fall down!"

"Well, a stack is basically like doing that with data. You set up a data structure in a way that you can only add things to the top or remove the element on top. It's useful for keeping track of things that you're partway through doing, but you need to do something else first, and then before you finish that you need to do something else, and so on." (Thus introducing the idea of a call stack.) "Except that you don't want to knock the tower down in this case."

"Oh, I get it now. Cool!"

Answer 6

Don't feel bad. I had to explain what copy on write means to a complete and utter nitwit last week. Horrifically, that nitwit was one of our vendors.

If in person, find a white board, or at least some paper so you can become a human layer of abstraction.

If working with someone remotely, there are many sketch / white board tools available.

Attempting to simplify something abstract, by abstracting it further, without some kind of visual aid is just madness. It will lead to things like drug and alcohol abuse, disenfranchisement from your family and peers and worse, unicorn cruelty.

Answer 7

+1 for anyone talking about analogies, +1 for anyone talking about whiteboards or paper and pencil as visual aids.

Another trick I've learned, is that some people I've found if I write 5 pages about why something is, they will actually read it - I can tell, because a month later they'll say something and I know its from the document I wrote.

The odd thing is, I'm sure I had tried to explain the exact same thing verbally prior (even with visual aids and analogies) and they had not understood. I find this is especially helpful in political or emotionally charged situations or when frequent interruptions take things off course.

Do make sure to actually explain the problem however - and explain the why in terms of business benefit. Once I explained the concept of technical debt to our CEO - and now, we can use this as conversational shorthand. "Why do you want to do this three day thing ? That web page looks fine to me!" "It will remove technical debt, in that next time we have to fix it things will go much faster." Then, the conversation can become about how much faster.

Answer 8

You're doing yourself an emotional and career disservice by getting upset in having to explain technical details to non-technical people. The fact that non-technical people need you to translate technical processes to non-technical business processes and vice-versa is what got you employed. The more proficient you are at translating between the two problem domains, the more valuable you become to an employer.

Familiarize yourself with manufacturing techniques, and explain the development process in terms of assembly line processes.

For example, explaining the processing of html tags (and thus the inability to use them) can be expressed in terms of extrusion dies, popularly known in play-doh.

Explain the problems of development process, such as changing requirements, updating interfaces, product defects, etc., in terms of the cost of shutting down the line, the time & expense spent building the line and having to modify it when requirements or conditions change, etc.

I went into more detail in another answer.

Answer 9

• Consider it a great opportunity to hone your presentation skills.

• Consider it a great opportunity to review your technical fundamentals.

• Speak in the language of the audience, NOT your language.

• Investigate WHY the non-techie wants this information. What's the underlying reason? Is he bored? Curious to learn more? Wants to appear competent? Likes to drive you crazy? Super-extroverted with no one to talk to? Frustrated by your lack of progress despite your optimistic estimates (that's a common one!) ?