I'm a programmer who is trying to explain a concept to a non-technical person, in particular the Azure Event Hub and Big Data.

I also need to explain why there is an elephant on the picture:

enter image description here

When speaking to an audience with diverse and non-technical backgrounds; how can I effectively relate concepts to them?

The path taken to get to a simple, clear explanation feels like "intellectual factorization" of sorts.. and that some smart person has probably analyzed this process into a framework for communication.


I'm looking for a structure, a process, or technique I can use to simplify concepts ...and then organize the thoughts so they can be understood. Does this exist, or is there any method I can use?

Educators, and technical marketers likely have this information since they need to use this in their day-jobs.


Recently, I found that using the abstractions "tool", "function", and "process" seems to work well.

  • What is it? (the noun name... isolation layer, ORM, etc)
  • What does it do? (sort, save, calculate)
  • How does it relate to the other pieces? (the line, and the endpoints of the line)

This is what I've picked up along the way, but think there must be several approaches for different types of learners. (e.g. visual learners, people who must write it down, or those with different intellectual propensities)

  • 2
    Who exactly are you trying to communicate with?
    – apaul
    Commented Sep 20, 2017 at 14:11
  • What do they want to know exactly? What is the bottom line for them here?
    – johnny
    Commented Sep 20, 2017 at 14:32
  • 2
    Its not really relevant to the question but, Im dying of curiosity- what DOES the elephant represent? Commented Sep 20, 2017 at 20:40
  • 1
    @kingfrito_5005 a child's toy. :-) Commented Sep 20, 2017 at 21:52
  • 1
    Yes, if you're asking how to have a conversation with somebody, it belongs here. Good luck! Commented Sep 20, 2017 at 22:31

5 Answers 5


Business Development Manager needs to understand from you as far as you know:

  1. What problem does what you've done solve for a real person/animal/company?
  2. Who experiences this problem (pick one example) and what is it like for them before you came in to solve the problem? (E.g. For 1&2: HR managers find it difficult to store files in the cloud because they usually work in caves so access to WiFi is non existent.")
  3. How do other ways of solving this problem still let this person/animal/company down? (E.g. HR managers tried uploading files via 3G but the network kept crashing. They tried via 4G but it took 2 hours to upload file. Highly impractical as they need to upload 10 files a day on avg)

  4. Your solution - bring back this HR manager and show how he could use YOUR SOLUTION - e.g. instead of WiFi, 3G and 4G, the HR managers could plug into their laptop this Ethernet cable (which you invented, your solution) and this cable would 've connected straight to the cloud and they'd be able to transfer their files in 3 min on avg per file.

Good luck! :-)


Explaining technical things to non-technical people is a great skill, one I do not claim to master. I can give some tips though.

  • Try to avoid as much detail as possible. Every detail you mention gives the listener a chance to lose your story and give up.

  • Focus on a story. In the graphic you show, there should be a logical flow through the flowchart. What are you doing at each step? What is your goal? What is the elephant trying to accomplish.

  • Focus on the why, and not the how. How's are generally details that get technical fast, so they are not interesting to laymen. Rather focus on what you are trying to do and why this is important.

  • Work with an example that updates as you go through the flow. Doing this, allows people to relate to what exactly is happening. Preferably you use an analogy that makes it more relatable. Like comparing network traffic to a parcel being sent.

  • This is good. Keep in mind that your audience has their own level of technical skill relative to their job. For instance, if I were to be in a room with a sick person, I'd run to find a nurse. They'd know what to do there, or if someone is bleeding. I wouldn't. Also, think of services, not tools. "We provide connection to the network". Skip DHCP, networking topology, storage, data transfer rates, failover, etc. Think of what your audience cares about and work from there. "It is the mark of understanding a complex subject when you can explain it to a novice so they understand." Commented Sep 24, 2017 at 1:56

To my knowledge your best bet is to build upon a metaphor or abstraction which the audience can relate to. If your audience is homogeneous it's easier to build upon a concept they are very likely to understand, which becomes more important and useful the more technical the concept becomes. The term technical debt is a great application of this technique:

I coined the debt metaphor to explain the refactoring that we were doing on the WyCash product. This was an early product done in Digitalk Smalltalk, and it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along and to look as if it had been easy to do in Smalltalk.

The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.

Naturally not everyone is in this line of business and someone neither in a software nor financial business might not understand anything from that. This means that the more common and natural a metaphor you can make the better it will translate in the audience's minds. A great case in point would be to compare traffic over the Internet as physical mail (I doubt it's a coincidence we refer to IP packets the way we do).

If you can't find a good metaphor for, say, ORM which your audience can relate to it's very likely that you're attempting to describe something way beyond their understanding. Unless it's integral that you explain this then you should simply ignore it or refer to it as "magic that just happens". The latter is not very stylish but you can include some additional reading on the subject later on, simply indicate that it's a complicated subject.

The book Metaphors We Live By written by George Lakoff might be useful for you to read. It's on my reading list but I haven't reached it yet so I can give no indication on whether or not it would help you.

For the record, Wikipedia has a very interesting list of commonly held misconceptions which states the following about learning styles:

All humans learn in fundamentally similar ways.[348] In particular, there is no evidence that people have different learning styles,[348] nor that catering teaching styles to purported learning styles improves information retention.[349]


I like talking to my wife about work because even though she is not a programmer, she is keen on knowing what I did at work today and what it means. She is smart enough to grasp the basics of it all. When I explain technical/programming stuff to my wife, I always compare the technology to a real tangible object. For instance:

I was recently working on a project where I had to move a Sharepoint application out of Sharepoint and make it its own website, then upgrade Sharepoint.

This is the analogy I used when describing that project:

Me: It is like a pot of soup. The soup is still good, but the pot is really old and rusty. So we need to get a new pot. It isn't possible to do it with the soup still in the pot. I mean, it is, but it is very hard. You need to take the soup out of the pot and pour it in a different pot, then buy a new pot. The soup is the website, the old pot is old Sharepoint, and the new pot is new Sharepoint.

Her: So why did you have to make it its own website? Why not pour it out of the old pot as it is?

Me: Because no two pots are the same. Soup that was in one form in the old pot cannot be in the same form in a temporary pot.

Likewise, use real life tangible objects to compare with your technical topics. Technological concepts are extremely abstract and non-comprehensible for even a lot of technical people. Technical people can somehow make a connection in their heads with other technical stuff they know to be able to comprehend something new. Non-technical people need that connection to be something that is not abstract/non-technical.

This is just one idea. I am sure others would have much better insights on this.

Also, I have no idea what that image is trying to describe. So I couldn't directly give you an example related to that.

  • 4
    Also a programmer here, that flow chart is gibberish to me too. The fact that technically informed people don't understand it (without context) suggests its just a pretty crappy flow chart. I am genuinely curious what the elephant could possibly be. Commented Sep 20, 2017 at 20:17
  • I was thinking about the elephant too!! :D Commented Sep 20, 2017 at 20:36
  • He has watched a lot of videos from conferences. Some of the folks, if USA, would immediately wonder what Republicans have to do with this.
    – johnny
    Commented Sep 21, 2017 at 15:06

Imagine you are teaching someone to drive. Start at the concept of a wheel, axles, gear ratios, then maybe combustion, the combustion engine and so on.

Or, you put gas in the car, turn the key, push gas, etc. You give a product demo like a car salesman would, not a car designer.

You did not mention the bottom line enough for me to know what to say, and I realize it is private, but this guideline will help.

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