The curse-of-knowledge is a common cause of technical miscommunication, especially when technical terms are involved. Here are a few ways to notice when it is happening to you and how to avoid it.
The Curse of Knowledge
By far, the biggest problem when it comes to technical communication is a bias known as curse-of-knowledge. This bias occurs when someone unknowingly assumes that their audience has knowledge that they don’t actually have. It’s happening to me even as I write this post. I feel like readers must already know the information, but after giving several workshops on similar topics, I know that probably isn’t the case.
My favorite curse-of-knowledge example happened to me during a trivia night. A group of friends and I were participating and there was a question that came up about video games from the late ’90s. Having grown up on video games, answering this question was very easy to me, but one of my friends felt like it was unfair. He felt that trivia should only contain questions that you could reasonably come across in your daily life, and not an obscure fact you have to go out of your way to study. I asked him for an example of a topic, and he responded with “sports,” which made me laugh. I told him my family rarely even watched the Super Bowl, so I picked up many more video game facts than sports facts in my daily life. (I also had to explain that the point of trivia actually was to learn obscure facts.)
Without the previous conversation, my friend could have started talking to me about something involving a sports team without any context. In his mind, he’s explaining everything well, and we’re on the same page. Unfortunately, I would have had to spend the first half of the conversation trying to figure out what sport they played, instead of being able to process what he was saying. This is exactly the kind of situation you want to avoid in conversations with stakeholders because it can waste valuable time and inadvertently make you feel unaccessible to them.
The good news is that there are some ways to catch yourself falling prey to curse-of-knowledge.
Avoid Using Nouns When You Can Use Verbs
You probably haven’t thought much about grammatical structure since writing papers in college (or maybe even before that), but it’s critical to understand when you’re trying to communicate complicated concepts.
When a verb is transformed into a noun (like how “acquire” becomes “acquisition”), it is called a nominalization and can be a sign of curse-of-knowledge. Sometimes nominalizations can be useful: for example “interviewer” and “interviewee” make it easier to communicate who is performing the action of interviewing. However, they can often make the sentence passive, which makes it harder to understand because it obscures the actor. For example, if Bob says “There was no anticipation of problems,” he can avoid saying “I did not anticipate any problems.” While this is a nice trick when you’re doing it on purpose, if you notice yourself using a lot of nominalizations in your communication, try to practice turning those nouns back into verbs.
Definitely Avoid Stacking Nouns
Nominalizations also encourage the use of noun clusters. The English language allows nouns to modify other nouns, which removes many of the grammatical clues people use to interpret a sentence. These clusters are usually a sign of curse-of-knowledge because when humans learn concepts, they start to group them.
Think about the phrase “paid customer acquisition channel.” The meaning is obvious to most people reading this post because customer-acquisition-channel is a single concept for them. Once you know how it should be interpreted, it’s almost impossible to think of any other interpretation. But if someone doesn’t know attribution concepts, it’s hard to tell what noun is the focus of the cluster. They could easily interpret it as a paid customer’s channel for acquiring something.
You can fix this by changing some of the nouns into verbs and using hyphens to clarify the true subject of the phrase. A sentence is easiest to follow if there is a clear subject doing a clear action. If you weren’t sure your audience knew the definition in this case, you could change it to “a paid channel to acquire customers.”
I often notice myself using noun clusters when I’m building decks. My first instinct is always to title a page with just a string of nouns vaguely describing the data such as “top customer lifetime value affiliate customer acquisition channels.” It’s better to replace that with a specific insight, such as: “Customers acquired through ABC Rebates have a higher lifetime value than any other affiliate.” Framing it as an insight helps for two reasons. First, it makes it easier to think in terms of subject-action, which helps avoid noun clusters. Second, it usually makes the sentence more concrete, which improves audience engagement and understanding.
Avoid or Identify Jargon
Most people already know to watch for jargon and acronyms, but sometimes it can actually be beneficial to use them. Often, these are still noun clusters, just more widely understood ones. There are many examples of this in online advertising such as SEO, PPC, and PLA.
Because they are more widely accepted, using jargon and acronyms can be a more efficient way to communicate. For example, it would be a little ridiculous to continually say search engine optimization instead of SEO if you’re in a digital marketing meeting. However, at a meeting with sales reps, the concept might be more foreign.
It’s also important to be aware of which terms are company- or team-specific. At one of my jobs, we had a channel called GOA, which stood for General Online Advertising. Almost no one knew exactly what attribution sources fell into it because the title gave very little context. I learned very quickly to avoid referencing GOA at all and instead just using the more understandable source breakouts for most conversations outside my immediate team.
So what’s the best way to handle the use of jargon and acronyms in communication? You can simply avoid them so that you can guarantee everyone in your audience is on the same page. However, I often prefer a compromise. I use industry-standard jargon and acronyms, but I give a brief explanation the first time I use one (you can see an example of this when I discuss KPIs in the following section). This method prevents you from coming across as condescending to experts in the field while still allowing non-experts to follow the conversation.
Keep the Other Person’s KPIs in Mind
Sometimes jargon is obvious, but many times what can seem like commonplace words can have different meanings to different people, making it much harder to notice. Transitioning from my job as a web analyst to a financial analyst really helped me see how often this happens.
I had worked at the company for almost a year when there was a reorganization that resulted in me moving to the finance team. When I transitioned to my new team, I assumed communication wouldn’t be an issue because, despite having no formal finance training, I had already been providing data and insights to the finance team for most of my time at the company.
During my training, my supervisor asked me to send him a report on how much money each of our customer acquisition channels made for the past week. I sent him a spreadsheet with two columns: one labeled Channel and one labeled Revenue. He immediately called me over and asked what I meant by “revenue.” I was confused because it seemed to me like the only thing to call it. He explained that, in finance, “revenue” is a very broad term. On this team, I would always need to specify whether this was demand sales, demand margin, net sales, or net margin. In the web analytics/ecommerce team, our primary fiscal KPI (key performance indicator) was demand sales, so everyone on our team understood what we meant when we said “revenue.”
Always remember to consider the other team’s KPIs when communicating anything. Even if you think you know what they are, it never hurts to check in from time to time because team priorities can change. It can help clue you in to potential miscommunications like these and guide you on how to structure presentations.
Being able to communicate effectively is one of the most important parts of any technical role. While it sounds simple, communicating scientific concepts to people outside the field requires careful thought because, as humans, we are bad at remembering that not everyone has the same knowledge that we do.
There are a few ways you can change how you structure ideas to help communicate them to non-technical audiences. First, avoid nominalizations (nouns made from verbs). For example, say “He spoke” instead of “He gave a speech.” Changing nominalizations back into verbs will also help with a second method: deconstructing confusing clusters of nouns. For example “web product provider” can be “company providing a web product.” Third, briefly explain any necessary jargon or acronyms when you first introduce them. Finally, keep the audience’s KPIs in mind. It can give you a baseline of their biases and understanding of your topic, which will help guide you on where you need to apply the previous methods.
About the Author
Sierra Broussard is a Data Scientist with a Ph.D in Cognitive Neuroscience from UCI, where she helped lead graduate-level workshops on effective technical communication. She has spent the last two years in digital marketing and has recently completed a fellowship at Insight Data Science. See Sierra’s work on her website or follow her on LinkedIn.