Overcoming Jargon
I was talking to a group of professors from James Madison University yesterday, when the topic shifted to “discrete event simulation”. They asked me if I knew anything about it – I said no. I don’t think I had ever heard of those words strung together in the same phrase, and so immediately assumed that this domain was just something I had never been exposed to. They also told me that they were using ProModel to do a lot of their discrete event simulation.
I’m addicted to learning new things, so I checked out to see what ProModel was all about so I would know what “discrete event simulation” was. And guess what! That’s the term for exploring different plant layouts to support manufacturing and assembly processes, for simulating new manufacturing processes, for designing kanban systems, for designing supply chains and other networks, for setting up queueing systems, for doing SPC and for managing your Six Sigma analytics. So I guess I do know something about “discrete event simulation”! I’m also wondering why I’ve never seen this DES product advertised in Quality Progress – it looks like it’s pretty good, and pretty comprehensive.
This reminded me that jargon can impede or enhance communication, depending upon the capabilities and understanding of the communicators. Neil Ward-Dutton, in a December 2006 post, collected some articles on this theme and reflected on them in “On jargon, and creating a common language.” He contrasts a message about the benefits of Web 2.0 presented in two ways: one filled with technical jargon, explaining the way it came to be, and one explaining the same thing but from the perspective of how Web 2.0 influences and affects people.
The use of jargon – or the avoidance of jargon – can communicate competence in a field or alienate people who need to know more.
Awareness of whether a term or a phrase is jargon can help us understand whether we are communicating accurately.
If I was aware of the nature of the term “discrete event simulation” I would have said “Sure! I really like discrete event simulation. In fact, I really enjoy designing plant layouts (which can be useful for designing software systems too), I am insanely enthusiastic about inventory models, and these are the kinds of analytical things that we do in Six Sigma projects all the time.” But no, I missed an opportunity to communicate – and maybe even to learn new things about modeling – because of jargon.
It reminds me of when I was a meteorology student several years ago. In one of our dynamics classes, I was dumbfounded by the number of times the professor referred to “zonal” and “meridional”. I had no idea what these two words meant – I could guess, but I might be wrong – so I searched all through our textbooks to find anything that would tell me about these two words. They were NOWHERE. And the dictionary was no help either. So one day I asked the professor, in class, what “zonal” and “meridional” meant. Her response is etched in my psyche forever: “If you don’t know what those words mean, then you shouldn’t be in this class.” Now this was in the days before Google, so I couldn’t just go look it up. What do you think I did? I felt totally embarrassed, crushed because I didn’t know something that was apparently so easy, decided to hide my lack of knowledge, and struggled through the class. I was even too embarrassed to ask my classmates. Years later, when I figured out the answer to my simple question, everything fell in place and I understood what went on!
The far more constructive answer from my professor would have been: “Zonal refers to the east-west direction and meridional refers to the north-south direction. So if we have zonal flow, it’s oriented predominantly east to west, and if we have meridional flow, it’s oriented primarily north to south.” My response would have been “Excellent! That’s simple! Now I understand what the equations are trying to say!”
The lesson here: no questions are stupid. Sometimes, a stupid question just reflects that someone’s trying to break through the barrier of jargon. This is a positive thing – it means they’re trying to figure stuff out! After this experience with my dynamics professor, I vowed that I would never think someone was totally stupid if they were asking (what I thought was) a simple question. I hope my coworkers and staff members feel that I’ve followed through on this.
(It reminds me of another time in that same course. We did a lot of multivariate calculus and differential equations, and the professor kept referring to “zed,” but for the life of me I couldn’t find the “zed symbol” in any of the equations. And none of my books would tell me what the “zed symbol” looked like. I’ll leave this joke as an exercise for the reader.)
love this post and tweeted about it this aft as well.
must ask, though, what really IS lean six sigma anyway??? Jargon. 🙂
I am really glad you mentioned this!! Yes, “Lean Six Sigma” is total jargon. And it took me three out of five years in a PhD program – where quality systems is the main emphasis! – to convert this term to what it really means: eliminating waste and achieving flow (lean) while reducing variation (Six Sigma). Unfortunately I think that most people in business haven’t had the opportunity to spend so much time reflecting on the term’s meaning, and so it has achieved a mythical status with high billing rates for its consultants. I did write on “what is LSS” earlier (https://qualityandinnovation.com/2008/10/18/what-is-lean-six-sigma/) and also how to do a LSS project (https://qualityandinnovation.com/2008/10/11/how-do-i-do-a-lean-six-sigma-lss-project/) – but not in quite so stark terms. They might also be interesting reads for you. Thanks for the note!
Zed – love zed. Had I not had english relatives I wouldn’t have known zed either. Certainly gave me a leg up on this semesters 703 capers!
Pingback: The Genius of Asking Dumb Questions « Quality and Innovation
Pingback: The Quality and Innovation Attitude « Quality and Innovation
Pingback: ARTICLE: Overcoming Jargon | amandajwaller
Pingback: Bridging the Communication Gap Between Technology and Customer Needs - Etchasoft
Pingback: Bridging the Gap Between Technology and Customer Needs - Etchasoft