1. The curse of knowledge

You are explaining something you have done a hundred times yourself. You move through it briskly, because it is not complicated. The group nods, nobody asks a question, and you move on. Half an hour later, during the exercise, it turns out that half of them got stuck at step two. There is nothing wrong with your knowledge and there is nothing wrong with the group. What goes wrong sits in between: you explain from what you know, and they listen from what they know. The further apart those two are, the less gets through.

Everyone listens from within their own frame of reference

Your frame of reference is everything you bring with you when you listen to someone: your knowledge, your experience, the words you know and what you expect to hear. Your frame as an IT specialist is full of terms that are everyday fare to you. Cache, profile, instance, rights, environment. To the administrative assistant who has to work with the new software tomorrow, these are empty words, or worse: words that make them think of something different from what you mean.

On top of that comes a second rule that explains a great deal: meaning is not determined by what you intend, but by what comes across at the other end. "This really is very simple" is meant to reassure. Someone who does not understand it hears: and you do not even get it. From that moment on, they stop asking their question. That is how you lose the feedback you need in order to know whether your explanation is working.

The curse of knowledge

The curse of knowledge is the phenomenon that, once you know something well, you can no longer recall what it was like not to know it. You see the action as a single whole, while for someone else it consists of twelve separate clicks. You skip the step where you first go to the right tab, because you do that with your eyes shut. And you can no longer sense which words are jargon, because every word you use is an ordinary word.

You can recognise it from three things. The first is that your explanation moves faster than your hand: you are talking about step four while your mouse is already at step six. The second is the phrase "and then you just", where the word just conceals a whole action. The third is that you get questions that surprise you because they are about something you had moved well beyond in your own head.

The remedy is not to tell everything more slowly and in more detail. The remedy is to write the task down once as someone who does not know it would carry it out, click by click, and then see which steps you skip in your explanation. That costs you fifteen minutes and it buys you a calm day.

Translating jargon without using other jargon

Every technical term you use is a choice. Sometimes it is necessary, because the participant sees the word on their screen and needs to know it. Often it is not necessary and there is an ordinary sentence that says the same thing. The translation only fails when you replace one piece of jargon with another: "an instance is simply a separate environment" gets nobody any further.

A translation that does work names the action or the consequence. Not "this runs in the test environment", but "what you do here has no effect on the real data". Not "you have no rights to that folder", but "that folder belongs to another department; you cannot get into it". And if a term does appear on screen, mention it once along with the explanation and then use it consistently. Switching between "folder", "directory" and "location" for the same thing costs you more than the difficult word itself.

Back to what the action requires

The second source of noise is not your language but your volume. Every extra detail competes with the essentials. What can usually go is not the content itself, but the context around it: how the software came to be the way it is, the three routes that lead to the same screen, the exception that applies in December, and what was different in the previous version. To you, that is all part of the story. To someone performing the task for the first time, these are extra turnings on a road they do not yet know.

On the left is the explanation as it often sounds: the five steps themselves on top, and beneath them four layers of background that have been added over the years. On the right is what the participant needs now, namely those five steps, with a car park alongside for the rest. The part you leave out does not disappear for good. Background, alternative routes and exceptions come back at the moment the participant has carried out the basic action once themselves. By then there is a peg to hang them on; before that there is only a pile of unconnected facts.

A practical measure: can you write the action down in five steps or fewer? If not, there are probably two actions in one explanation. Splitting almost always achieves more than compressing.

Words that weaken your message

If your explanation is sound and your volume is right, what remains is your wording. Many trainers unconsciously sprinkle in hedging words: actually, a bit, just quickly, I would say, perhaps it would be useful to. They sound modest, but the group hears doubt. "We are just going to have a quick little look at the settings" promises nothing. "You are now going to set three things that determine who may see your files" promises something concrete, and the participant knows straight away what to look out for.

The same goes for the negative form. "Do not save the file on the C drive" leaves the other person guessing what they are supposed to do instead. "Save the file in the team folder on the network drive" is an action someone can carry out. And abstractions are not instructions: "pay attention to security" is an appeal without a button, "switch on two-step verification before you log out" is one with.

Finally: whatever you say only once will disappear. For each section, choose one key sentence of no more than twelve words and repeat it three times: when you announce the topic, while you demonstrate it, and when you round it off. In a stream of details, that is the only thing the group has to hold on to.

Summary

• Everyone listens from within their own frame of reference; where yours and your participant's do not overlap, noise arises.
• Meaning is not determined by what you intend, but by what comes across. "This is very simple" makes people keep quiet.
• You can recognise the curse of knowledge from three signals: your explanation runs ahead of your hand, you say "and then you just", and questions take you by surprise.
• Translate a technical term into the action or the consequence, not into more jargon, and then stick to one word for one thing.
• Reduce your explanation to what the action requires. Park background, alternative routes and exceptions until after the first successful attempt.
• If the action does not fit into five steps, there are two actions in it. Splitting works better than compressing.
• Cut out hedging words, turn negatives into an action, and repeat one key sentence three times.