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

  • 8
    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, 2010 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. Oct 14, 2010 at 14:35
  • 1
    Possible duplicate of: Getting non-programmers to understand the development process
    – user8
    Oct 14, 2010 at 19:47
  • 1
    @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 :) Nov 19, 2010 at 11:28
  • 1
    You don't. What you do is try to understand why the question is asked. So you shouldn't dumb anything down, rather you should smarten up and understand the perspective of other part in a communication. E.g. why are you saying thing like "certain HTML tags are not allowed" to a non-technical person in the first place? The one you are talking too will naturally assume he need to understand it, otherwise why would you say it? So the correct answer is "sorry I'm blabbering, that is just an irrelevant technical detail, don't worry about it" and then get on to the important stuff.
    – JacquesB
    Apr 1, 2016 at 8:59

9 Answers 9


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.


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)
  • 8
    Off-topic, but I'm curious: how do you explain object orientation using a deck of cards?
    – Arkaaito
    Oct 13, 2010 at 4:19
  • 1
    But cards themselves don't really do anything; they're just data storage. Aren't you leaving out one half of the object-oriented equation? I suppose maybe if you look at the deck level...
    – Arkaaito
    Oct 13, 2010 at 4:32
  • 3
    @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.
    – Tarka
    Oct 13, 2010 at 4:45
  • 4
    +1 analogies are great. "You do not really understand something unless you can explain it to your grandmother." Albert Einstein
    – Nikki9696
    Oct 13, 2010 at 17:43
  • 2
    @Nikki Or, in my case, my grandmother's sister
    – Tarka
    Oct 13, 2010 at 18:34

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.
  • 3
    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
    Oct 13, 2010 at 10:06
  • 2
    @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, 2010 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, 2012 at 0:04

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.

  • 3
    +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. Oct 14, 2010 at 17:34

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.


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

  • 2
    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. Dec 7, 2011 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, 2011 at 1:20

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.

  • Whiteboard or paper and pencil works magic.
    – Kyle
    Dec 7, 2011 at 21:03
  • That shouldn't be too hard to explain...was it really? The fundamental I would start from to explain "copy on write" is that a file isn't really a file, it's more like an index card in a library. You can have "two files" that point to the same actual stored data, just like index cards can both point to the same actual stored data. From there it's a very short leap to copy on write.
    – Wildcard
    Apr 1, 2016 at 6:42

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

  • 2
    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, 2012 at 0:08

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.

  • 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!) ?

Not the answer you're looking for? Browse other questions tagged or ask your own question.