Discussion on:

Could you explain technology to a non-IT person?

Thank you, Ms. Bowers, for bringing up a great topic.

I have always believed that life is better when it's in layman's terms. I learned that in college, in a macroeconomics class. My professor (who probably never wanted to be a teacher anyway) would lecture straight from the textbook, and, in between bites of soft pretzel and nips of Diet Coke, prattle on about the conceptual and empirical linkages between mass-market foodstuffs and taxable intoxicants.

I was in danger of failing the class. Plus, he made me feel stupid.

It's only when he began to teach theory using everyday examples, like pizza and beer, that I began to grasp the concepts. (Not that I am a fan of either.)

The very thing that inspired (or didn't inspire) the aforementioned economics professor's pedagogy is alive and well in some of the folks who staff the average corporate IT department.

As you pointed out, knowing how to explain jargony subjects without jargon encourages IT/business alignment, which is becoming increasingly important with the growing reliance on fewer workers for the same amount of work, social networking and Web 2.0.

Think about the last time you called the help desk. Did you need two hands to count the number of acronyms that were used? Did you walk away feeling empowered? Will you be so quick to call back when your Excel formulas rebel?

I doubt it. And that's the point: Alienating the rest of your company is not alignment. Indeed, understanding how technical tools and practices relate to the business as a whole, now that's an idea.

And regarding that macroeconomics class -- I passed with a perfect grade.

Thanks again.

Jen Darr
blog.pchelps.com

I agree that this is an excellent topic. I would also suggest that it starts even before the interview when looking for a job.

Our resume and letters should be created with this concept in mind, as well. We don't know who will read our resume during the search process.

For example, if I follow a proactive job search model and interview contacts about their businesses, I could be talking and presenting my resume to people who know little to nothing about IT. What they do know a lot about is a business that may sooner or later need someone for a technology position.

When I leave my resume, it needs to contain the same lay language in which I speak. I should not have to explain my resume. It needs to stand on its own.

Happy Holidays!

If HR wants to post a job description with an alphabet soup of acronymns and buzzwords, they should expect to get resumes that do the same.

I often try to explain IT to younger children. Once while trying to explain the way information is stored in folders to a small group of students, I used the example of their hometown, neighborhood, house and room. As the children began to nod their heads in understanding, I turned around to find an adult nodding his head saying "I get it now!" You must find their level of understanding and go from there.

When I taught at a tech school (adults) I found that telling them ahead of time what I would be doing really helped.
A DOS class was told that the first half of the course would be giving them pieces of a picture puzzle (the commands), and the second half would be assembling them into something useful (programs).
They always understood what they were in for.
Although I later realized that this was a form of the military - Tell them what you are going to tell them, tell them, then tell them what you told them - I felt that I had invented something at the time. Oh well.

I can argue, that as an IT Pro, (or any specialized SME) it IS your job to be able to teach your colleagues how to do your job.

When composing training material, I use 3 basic concepts to get my point across:
1. Tell them what you are going to do.
2. Teach them what to do.
3. Show them how to do it.

1. Gives a heads-up, so that the students are prepared for what is coming.
2. Is the training.
3. Is clarification of the training with lots of pictures.

Les.

doing or want to do to those who have to approve or fund it, or work with it afterwards. If you work in a back room with absolutely no contact with non-IT people and just work on the computers all day, then you don't need to be able to explain, but just about every other iT job requires interaction with non IT people, and you need to be able to explain things to get your message across and to find out what you need to know from them.

This posting reminds me of a piece I wrote that covers the details of the skills a good consultant or business analyst must have to be successful in today's economy... This article covered the details and requirements of each of the skills.

Screening Methods to Find the Right Consultant ? Part 2
http://www.r3now.com/screening-methods-to-find-the-right-consultant-part-2

Important consultant and business analyst skills
? Facilitation skills
? Meeting skills
? Process mapping
? Business case (or whitepaper) development
? Problem solving
? Organizational dynamics

for a business analyst. You will pull those requirements off of any reasonable description of a BA position.

Les.

Up until recently I spent my days working with accountants and book keepers providing technical support. Most of my clients PC skills were very limited and I learned very fast if wanted to be successful I would have to find a way to dumb things down so they would understand.
I found that my clients appreciated that I would bring things down to there level and did not come across as better than thou. Because of this my client interactions were shorter and less painful. which gaveme more time to surf / lurk on TR.

A geek who's able to get out of the box and explain in simple terms, definitely has a plus.
Handling abstract concepts and translating them to the listener's "OSI layer" takes double brain work than just thinking of them.

Taken to the extreme, prophets from all religions were able to talk wisely but in people's words.

Easily anbody can explain. Since no one is expert since birth.

I think I can explain, but it really takes time.

Very interesting thoughts to think about.
I agree that every IT skills you have in the industry will be of even greater value if you can "translate"
it to the lay-man out there. You can be a pro in the back of the office but if you out there in the field, it's a total different story. Thanks for the thoughts, Toni

Each year I have to present to our directors at their conference on a subject concerning the forthcoming budget. Working for a law firm I have always tried to use the 'lay-man' speak as lawyers invariably think they know it all but actually don't!!

One year I played a variation of 'Who Wants to be a Millionaire' with them, with each level and monetary value being represented by an item on the proposed budget. The questions in between were also ICT related and I even set up a 'phone a friend' to my systems manager, which was used (and he did get it right)!!

Last year I talked about Virtualisation. So I got 10 directos to stand at the end of the room each with a sign stating which one of our servers they represented and how much 'utilisation' the server represented. To get the feel for how little they were doing I got each one to either march with their left, right arm, right leg, left leg or nod their head. So i had 10 of my senior directors up in a room semi marching. To represent what virtualisation meant I then got the new MD and FD forward and passed each movement from the others to them, so eventually both of them were fully marching on the spot and nodding their heads (by this point they were starting to sweat a bit....they are not the healthiest). Whilist pointing out that we now had two servers which were working harder and doign exactly the same jobs I then flicked on to the screen behind them and up came the following (apologies to our American friends as they may not know who this is .... http://www.youtube.com/watch?v=_YoACJo4-XY
(the bit with Mr Blobby and Jim Bowen)
Needless to say they do now appreciate what virtualisation is, even if they havent given any budget to start the project !!!

and well explained.

... and making no progress with the idea that the operating system installed on the VM was made to "think" that it was installed on the physical hardware.

Inspiration struck when the other person happened to mention that she enjoyed Star Trek. "Well then," I suggested, "just think of a virtual machine as a holodeck for an operating system."

No further explanation required ;>)

I have struggled to explain virtual machines to, well, just about anyone who doesn't work with them. This is a brilliant analogy and I look forward to using it extensively. Thanks for sharing.

people is to say the VM is a damn good actor that dresses up in the clothes of another operating system - they usually get the message then.

Steven Hawkings is perhaps the best example of such a person. A true genius who can explain quantum theory in a way that is quite easy to grasp. I would recommend reading "A Brief History of Time" to understand his real genius and talent.

...then this is what you do all day. Most support technicians are better equiped to discuss IT than the "experts". Also they don't have the drawback of being fixated on a single area of IT at the expense of all others.

During an interview last year I was asked to explain networking and server concepts in layman's terms. The entire interview focused on this method of questioning. They asked questions like "what does a firewall do and how will it help my business be more secure", "explain how selling me a server will provide central management".

recognised this as a problem. I learnt most of my early IT stuff by do it yourself hands on and teach yourself from text books. When I finally got around to doing some actual official IT training, about 20 years later, and get some certificates to paper the wall with, I found a lot of students couldn't understand what the teachers were saying as they ALWAYS explained things in IT tech words - assuming the people already knew them. This was at a tech college and the teachers were IT people who'd picked up some sort of teaching qual along the way.

The hardest hit with failures were the programming courses. In one course I did we had a lot of women with an interest learning programming as they could do that at home while still caring for kids before and after school. The two aspects most hadtrouble with were - setting out global variables at the start, and the importance of keeping to the structured order. I was able to explain the concepts to many by simply relating computer programs to programs they've been working with for years - recipes, take a close look and they are set out the same; set up the list of variables (ingredients), and process in the correct order. Also, I found most people could see the correct order concept better if you suggested that they try having a shower BEFORE they take off their PJs one day, and see how well it works.

Most IT concepts lend themselves to such everyday analogies.

My company sells security products - anti-virus, data protection, network access control etc. One of the most important aspects of any anti-virus products is to ensure that the definitions are up to date. However, it is also vital to ensure that all the operating system security patches have been applied. We have been called out to a number of customer sites where there has been a virus outbreak and told that our software doesn't work. On inspection, we see that the AV software is up to date, but the security patches on the OS are not. It is at this point that I use a car analogy - keeping your AV software up to date, but NOT keeping your security patches up to date is like locking your car and leaving the windows open. Works every time!

Excellent advice here, as was your previous post recommending real-world analogies for tech concepts.

Having worked on both sides of the tech/business divide, I believe those of us in senior management roles often forget that business has it's own jargon that can undoubtedly be equally confusing.

B2B and B2C are maybe almost ubiquitous, but how many folks on your technical teams understand when you start throwing around acronyms like EBITDA, EPS, NPV, P&L, ROI and TSR?

There is an obvious benefit to clarifying our communication across a broad range of areas, not the least of which is helping people understand their role and the implications of their work in the complex machines that our businesses often are.

After all, written communication is just spoken communication but in the form of ink on paper.

The traditional form of writing/publishing is that if acronyms are to be used - the FIRST instance of each is presented in full, with the acronym in parentheses or brackets.

Why can people not do that when they're speaking?

that's all

.

Is this a professional blog thread? If so, then how about starting the educational process here?

This thread started with a post that tossed out several acronyms; none of which were explained. The second post makes a valid point about explaining the acronyms conversationally. In practice, this is a forum where the poster could experiment with methods to explain. How about attempting to rewrite the initial post in a manner that demonstrates a proposed solution to the problem?

As far as teaching is concerned, there are two obstacles to learning being demonstrated here. The first is the assumption that everyone knows some jargon, coupled with the assumption that this subset of everyone is familiar with some other jargon. The second obstacle is in the judgmental position about laziness that leaves the reader without any solution.

If you want to assert that people are lazy, then please start by getting over your own laziness. The word 'cause' is different than the slang 'cuz'. One must assume that you meant to state 'because'. I'll ignore the dialect in the remainder of the post for now, and instead heed my own advice.

I need to make some assumptions here. Deadly Ernest must explain his use of acronyms in his conversations, and feels that people who do not, are lazy. Apparently, Ernest does not wish to share his methods, and he does not respect the reader enough to use proper punctuation and grammar in his writing here.

Maybe people do not know how to inject the definitions of acronyms in their spoken communications. Will you please tell us how, and provide some examples?

I agree with kapspaz-itprof: A big rule of business is to SIMPLIFY communication. That being said, there is a sub-rule to it: Avoid using acronyms whenever possible. The IT industry is relatively immature, and the excessive use of acronyms muddles the clear exchange of ideas. I often cringe when reading articles and white papers, seeing so many acronyms that a non-IT person would be hopelessly lost. I believe a big part of communicating with those outside our "guild" is to clarify and define acronyms.

1. My response to OldER Mycroft was deliberately worded as humour, which you appear to have missed.

2. The word 'cuz' is slang for cousin where I come from, while cause is a commonly accepted short form of because (decided on in context) - written as 'cause or cause. To make life easier for you, I've made an edit.

3. I've already shared some of my analogies in earlier posts, and in some since the above reply was done too.

4. If you go through all the posts I've made to TR, you'll find I usually do explain acronyms, with the few exceptions of ones that have entered general usage - like BTW (by the way), CPU (central processor unit) etc. This is a habit I got into years ago. Too often I've seen arguments over acronyms, often where the same acronym has more than one meaning.

Suggestion for you - maybe you should read every post in the thread before making assumptions.

There is nothing worse than Marketing Hype in a technical help document ( could I mean Microsoft? ). It really confuses the situation.

Also the other big issue is the American / English divide. As an UK IT person, explaining American English explanations / help verbiage to UK residents really taxes ones story telling skills.

It was Albert Einstein that said "You don't really understand something until you can explain it to your grandmother".

On this basis, to ask a candidate to explain a concept in laymens terms will show that they really know what they are doing. I've used it a few times and it seems to give good results.

Excellent food for thought. I help people learn to tell digital stories, and analogies help a great deal.

one thing that occurred to me as I read the comments: there are tech conversations/confusions going on all over the world; and telling a clear story that connects with your audience becomes even more important across cultural divides.

I totally agree with the importance of being able to "speak English", i mean in layman's terms in the field of IT. Take mine as an example, during my early days I used to present our team's software project milestones/updates to various stakeholders, and the more we provide analogies to the tech terms which the program provides, the better they appreciate it and most importantly, they can easily formulate questions or arguments which would later help improve that system itself.

These days, I work as a 24x7 production support DBA for one of the largest US-based Retail Financial sector, and everytime I dodge Priority 1 infrastructure issues where Techs and Non techs convene on a conference bridgecall, Believe me, the business/stakeholders go real nuts everytime I accidentally speak alien technical terms while doing the fixes or providing blow-by-blow updates on whats being done to patch the hole.

I think I owe a lot from my training w/ Toastmasters Intl., few years ago when a boss from my previous company encouraged me to join such, in order to groom me for an elevated lead-roles frequently dealing w/ the line of businesses and 3rd party tech clients.

Really great topic and A goo quote from one of the commentators.

Yes it is the bes way when you hire some one from It ask him to explain something to I guy who dont know anything about.
Put him in to real life situation.

Does anyone know of a good analogy for explaining the benefits of OLAP cubes? Part of my job is promoting their use but I find them darned difficult to analogize.
With thanks in advance to all the analogists out there.

Good one!

I remember my best programming teacher. She explained variable data types as dog houses and the data that goes in them as dogs. Just like you can't put string data in an int variable, you can't put a great dane in a chihuahua's dog house. SNAP!!!!!!!

I find that saying 'databases are like a sewer... what you get out of it depends on what you put into it' has a greater effect.

Ah that's very similar to my expiation of bad/unusable info in databases.

I tell the users that a database is like a compose heap. If you put good things in you get out a good compost with lots of use, if you but in "un-digestible" things you just end up with a pile of garbage.

I learned very quickly how to relate to people on their level when I started teaching the MS products in the late 80's. We had a classroom open to the public in a MALL (that was so great). My first class was a group of seniors and they wanted to learn Windows and basic computers. I was throwing out all this tech stuff and I saw their faces lose color. So, I sent them to break and decided I need to rethink my game plan. When they came back we taked about vacations. You see a suitcase is a diskette, a harddrive - the attic in your house, CD...uhaul truck. I got rave reviews! I learned a valuable lesson that day...talk on their terms! Now, of course when I am in a room with Techies...we talk the talk!

It helps to be flexible in all situations!