Take the 2-minute tour ×

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?"

I'm ready to rip my hair out, these questions are driving me insane!!

share|improve this question



Personally, I love to stretch my mind and remember how "normal" people think. If I can't find a good analogy to explain it to someone, I need to take a walk and get away from the computer for awhile. –  Nikki9696 Oct 13 '10 at 17:47
Beyond "how" i would also consider the question "why?". If he's interested in becoming involved in technical details, i can think of more efficient ways for training. –  LennyProgrammers Oct 14 '10 at 14:35
Possible duplicate of: Getting non-programmers to understand the development process –  user8 Oct 14 '10 at 19:47
@Nikki spot on! I've been reminded time and again that even though I think I know how "normal" people think, I actually don't. I need a "normal" person to ask their question or state their theory before I realise how little clue I have about how "normal" people think :) –  romkyns Nov 19 '10 at 11:28
"how do I tell my manager to look the basic stuff up on Google" Give a basic overview, and then suggest they search on Google for more detailed explanations. –  jhocking Sep 26 '11 at 17:23
add comment

9 Answers

up vote 28 down vote accepted

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.

share|improve this answer
Off-topic, but I'm curious: how do you explain object orientation using a deck of cards? –  Arkaaito Oct 13 '10 at 4:19
+1 analogies are key. @Arkaaito: You could have a card interface and a deck iterator. Or perhaps a card parent class from which other cards inherit. –  webbiedave Oct 13 '10 at 4:23
@Arkaaito Usually using individual cards as good examples of inheritance and/or properties (depending on who I'm talking to and about what), and the deck as a container class that has functions like shuffle(), deal(), dealOne(), etc. –  Slokun Oct 13 '10 at 4:45
+1 analogies are great. "You do not really understand something unless you can explain it to your grandmother." Albert Einstein –  Nikki9696 Oct 13 '10 at 17:43
@Nikki Or, in my case, my grandmother's sister –  Slokun Oct 13 '10 at 18:34
show 4 more comments

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.

share|improve this answer
Whiteboard or paper and pencil works magic. –  Kyle Hodgson Dec 7 '11 at 21:03
add comment

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.

share|improve this answer
add comment

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 him understands what I'm saying, it might make him want to read those emails he was CC'ed on. Take time when writing memo's 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.
share|improve this answer
I always have people asking me what a database is, I normally say "Its like a series of excel sheets, or more complicated", but thanks :) –  Brandon Wamboldt Oct 13 '10 at 10:06
@Rouge: Simple is often far better. Learning to understand what they want to know is another bit. Non-technical people will often ask technical seeming questions by mistake. –  Josh K Oct 13 '10 at 12:17
@RogueCoder I've used the excel anology to explain databases too. "Its like a bunch of spreadsheets that are linked together, and you can aggregate all the data in any way you want by querying them" –  Tjaart Jan 31 '12 at 0:04
add comment

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.

share|improve this answer
+1 for this. When someone asks for an explanation, the first thing I do is establish a baseline: how much do they already know? You eliminate a lot of miscommunication by knowing exactly what you have to build on. –  Mason Wheeler Oct 14 '10 at 17:34
add comment

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.

Assembly line metaphor

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.

extrusion dies

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.

share|improve this answer
add comment

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?"


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


"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!"

share|improve this answer
Note how the non-techie in this example has an emotional connection to the analogy. That's critical in engaging your audience and getting them to want to understand what's going on. –  Stephen Gross Dec 7 '11 at 22:27
I work more in infrastructure than development and I find for most people their house is a very good (and emotional) analogy that fits many different scenarios: construction, inspection, maintenance, repairs, emergencies, renovating, etc. –  shufler Dec 8 '11 at 1:20
add comment

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

share|improve this answer
I managed to xplain technical debt to business folks, it bought me a lot of invaluable time fixing problems that had been creeping for years. Before I started every request took about 3-4 days to complete, when I was done some requests literally took minutes. –  Tjaart Jan 31 '12 at 0:08
add comment
  • 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!) ?

share|improve this answer
add comment
