8

Semantic noise refers to using grammar or (technical) language that the person you're talking with cannot (clearly) understand. I keep running into situations where I feel I am ruining a conversation for the person that's listening with this kind of noise, but I'm not sure how to stop doing it.

My main problem seems to be that the language I use when talking to friends, my brothers or co-workers is unsuitable for conversations with (most of) my family, neighbours or other acquaintances due to them not understanding parts of it. There is often a difference in highest education level between me and these people, with their highest education being a single to three levels lower.


A recent example: My grandma has had some medical old-age issues lately, and she's not very good at straight out asking the doctor 'what does that mean'. So, regularly, we'd be visiting and she'll tell us what the doctor said and ask us to explain. Last time, it was 'auto-immune disease'. Out of three people visiting her (grandpa, dad, me), I did know what that meant, but when I started explaining in what I thought was language suitable for a 12-year-old (bad virus/bacteria, immune system usually cleaning that up, but in this case attacking your body, which isn't an unhealthy virus/bacteria), I noticed that I was only confusing my grandparents more.

The same stuff happens when e.g. family/acquaintances ask for more details about my work (software engineering) after I already gave them a standard reply, when people ask me to explain something that's new to them or when we start talking about stuff that interests me (topics I've read books about, current events, a bit of philosophical or sociological stuff). Basically, this applies to almost every conversation I have with these people that goes a bit further than just the latest neighbourhood news or small talk. It seems I am confusing a significant amount of people I interact with, due to semantic noise.


As an added problem, my mom recently told me that some people (family, neighbours) told her the semantic noise seems to be giving them the impression that I am acting like some show-off, like I'm better than them, and that I get some kind of kick out of having them ask for clarification and showing 'they are dumb'. I could, of course, reduce my choice of words back to a level like the one used when talking to a toddler, but I don't think that would actually help reduce the feeling on their side that they are perceived as dumb by me.

So, as an added goal I'd like to avoid them feeling hurt by me talking in a way that's too difficult for them, but also avoid them feeling hurt because I talk to them like they're babies.

What are proven methods for reducing semantic noise in conversations that I can use to clearly communicate with these people?

  • Do you encounter this problem primarily when using technical jargon, or does it crop up more frequently? – Upper_Case Mar 11 at 18:35
  • @Upper_Case As far as I'm aware, it also crops up when using language that I personally would not call jargon. Unless 'server', 'bacteria', and 'immune system' are jargon ;-) – Tinkeringbell Mar 11 at 18:39
15

I'll challenge the phrase "semantic noise" a little bit. It makes me think of fluffy language, extra words thrown in that add little (if any) additional information (somewhat related note: grandiloquent was my favorite English word for a long time). That doesn't sound like your problem here. What you are describing is specific terms not being understood by the people you're speaking to, causing them to be unable to understand what you're saying. It's not a question of cutting out distracting, useless words, nor of making your point more quickly or explicitly. Instead it seems to be a matter of correctly assessing your audience and being prepared to make mistakes in those assessments.

1. Assess your audience

Different people have different functional vocabularies, and it is very difficult to determine whether or not a certain person will know a certain word without presenting it to them. It is also hard to get a sense of your own functional vocabulary, so "matching" someone else can be hard. That said, with people that you have known for an extended period of time it is possible to get a sense of how they talk, which I have found to be an excellent model for how to talk to them effectively. If my cousin always describes something oily as "oily" and never as "oleaginous", I'll try to only use the former. (I avoid "oleaginous" anyways, but that's a whole different topic).

2. Pick the right level of abstraction

Most jargon comes into play when summarizing a broad swath of information so as to allow fluid discussion. Outside of a more formal discussion you may be able to use less precise language. For example, when speaking with people outside of my department at work I almost always say "average" or "simple average" instead of "mean", even though a lot of people would understand "mean" in that context. I almost never say "arithmetic mean" because, while it's a very precise description it's also one that most people are not familiar with, and it makes a distinction (as from "geometric mean", etc.) which most people don't need to worry about most of the time.

3. Try to balance complicated ideas with complicated descriptions

Some ideas are very complex, and are casually referred to in more short-hand, vague ways. To say "immune system" is easy, and many people will have a good idea of what you mean when you say it, allowing you move on and discuss something more specific like infections, or autoimmune disorders, or a cytokine-storm immune response. They've already learned the one phrase, and so are ready to handle additional information. But there is a limit to how much information a person can absorb all at once, and so if you find yourself having to describe what an immune system is, then there might be a ceiling on much detail it's going to be possible to convey. You can fill in some of the gaps with analogy and iterative explanations, but there are limits. More complex, new information tends to mean less detail and a shallower discussion.

I feel stupid when I try to present the "puppet show" version of an idea, but if I don't feel there is an alternative that's what I'm left with. I used to have to explain health insurance policies to people a lot for work, and so my clients heard a lot about an analogy involving a bath tub, bucket, and faucet. I'd generally preface it with something like

I know this example might seem a bit silly, but people have found it clearer than the policy contracts in the past.

That helps get around the "why are you talking to me like you think I'm an idiot" response, and reiterates that I'm going for maximum understanding, not trying to comment on the person with whom I'm speaking.

4. Check in often

It's very difficult to assess what words another person will know without having witnessed it directly, as in (1). Using more succinct language assumes that the listener already has a certain degree of working knowledge, and being confronted with an expectation that you know something you do not can be jarring, especially if it happens over and over again over the course of a single conversation. So when I'm trying to describe something and think that my audience might get lost I try to check in at each conceptual "step":

OK, so imagine a bath tub, and inside that tub is an empty bucket sitting right below the faucet. Now, if we turn on the faucet, water will start flowing into the bucket, but none into the tub, right? In this example, the water represents your medical bills. The bucket represents your deductible, which you will have to pay yourself, and the tub outside of the bucket represents bills that your insurer will help you pay. So as water comes out of the faucet, it's going to fill up the bucket first, right? Keeping that image in mind, we can see that your bills will end up in different categories based on how much you've been billed so far... [and it goes on like that for a bit]

It's not a great example, but the bolded words are pauses where you can ensure that your listener is following you so far and offer more explanation if not. I've had good results with that sort of sequence, because it emphasizes that I want to make sure the listener understands each piece so that we can move on to the next piece. Regularly checking to make sure that you've sufficiently explained each piece makes it clear that you want the other person to understand what you're saying and are not assuming any particular knowledge on their part, lessening the impression that you want to demonstrate how much you happen to know that they do not.

As a bonus, this has also helped me fine-tune my assessments from (1). The real-time feedback on how my descriptions and explanations are working with various people has really helped me to examine assumptions that I've made and evaluate changes that I try out.

5. Assume that miscommunications are always your fault

I went back and forth on including this one, but it's a standard I hold myself to and I feel it provides the right mindset for addressing this type of issue. If I have subject knowledge that another person may not, then it's up to me to find a way to express it. It's never that your audience is too ignorant (or anything else, even if I may privately feel that that is the case), it's that I have failed to find a way to explain things clearly, and it's my job to find a better approach when one is failing. If, after a couple of tries, I'm just not conveying the message, I typically apologize for having explained things poorly. It can be humbling and frustrating both, but I think that it's done a lot to keep other people from feeling that I'm showing off.

  • 4
    Highly technical fields, like Software Engineering, requires forethought before it can be dumb-ed down. For example, if you were to describe the difference between a RDBMS vs a NoSQL database, it is unlikely you can do it off the top of your head, because introducing these kind of topics to the completely uninitiated is not something ever taught to you. – Nelson Mar 12 at 1:23
5

I can suggest a couple of strategies that I've found useful for providing more technical insight without unnecessarily confusing or showing off to others.

  1. Make your statement with some degree of self-doubt.
    By simply changing a statement from "An auto-immune disease is when..." to "If I remember, an auto-immune disease is when..." you bring yourself down from a position of being an authority on the matter to someone who has some passing knowledge on the subject. If You would like to then re-enforce your knowledge to overcome skepticism you need only add something such as "I'm pretty certain that's what it is, if you want I can find a source for it", in most cases this is enough to validate your point without alienating anyone.

  2. Use analogies.
    Often it's easier for someone to comprehend an analogy (even a poor one) than to immediately pick up on a foreign concept explained with detailed jargon. An example off the top of my head:

Imagine your immune system is like a city police force, they go around and try to detect bad cells. An auto-immune disease makes it so that some of the police get confused and start to think that a good cell is a bad one, and so they arrest that cell.

Hope this helps.

2

The other two answers are good and I just want to extend them with 2 points.

  • Adjust your explanation to the situation/timeframe. Is it a Sunday afternoon with friends where you can at lengths explain what a DB is to your family or is it a coworker who just asked you what you've been up to and that has only 5min and can't hear the full explanation of your latest project? Depending on how much time you judge the situation allows for, adapt the level of abstraction.

  • Start out with a default abstraction level that is very high and imprecise and see how people react. Often people don't want to know all the details but just hear some high level description and that suffices them. But ask them after the short explanation if they want to hear more details. Some things just take hours to explain properly. But with this approach the people can chose themselves how much detail they want.

I started teaching about a year ago and once you have to explain something you realize how much you don't know and how much of your knowledge is distilled knowledge and not knowledge that starts from first principle. It can be challenging sometimes to go back to these when explaining SE, because even if you heard why to not do or do X and it made sense at the time, your brain just remembers don't do or do X and you have to do some digging to find the justification for it.

In the end knowing something is not the same as being able to explain it. Train and have fun going up and down the abstraction levels of an issue, it will help you understand it better yourself.

  • Great points! Can you expand a bit on why this is a good idea? – ElizB Mar 18 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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