The Sender-Receiver Model: Why Your Message Never Arrives the Way You Sent It

By Brexis Wazik 12 min read -

A product manager tells her team, “we’re deprioritizing the mobile fix for now.” In her head, that means: still important, just not this sprint. In her engineer’s head, it lands as: mobile doesn’t matter anymore. Same sentence. Two completely different ideas, walking around in two different people’s heads, both convinced they understood each other.

This happens dozens of times a day, in every team, in every relationship - and almost nobody has a way to explain why. They just feel it when a message lands wrong and reach for the nearest vague diagnosis: “we have a communication problem.” Here’s a better one.

Why this matters

Most advice about communication is a personality trait dressed up as a skill: “be clearer,” “be more confident,” “listen better.” None of that tells you what to actually change on a Tuesday afternoon when your email gets misread for the third time this month.

The sender-receiver model does something different. It breaks communication into six distinct, fixable checkpoints - so instead of one fuzzy complaint, you get a diagnosis. Was the idea unclear even to you? Did you choose the wrong words? The wrong channel? Was there noise in the room, or in the other person’s head? Did they decode it through their own assumptions? Was there no way for you to catch the error before it became a real problem?

Once you can see the machine’s parts, you stop trying to vaguely “communicate better” and start fixing the one part that’s actually broken.

The core idea: nothing is copied, everything is rebuilt

In 1948, a mathematician named Claude Shannon, working with Warren Weaver, built a model to explain how information travels from one point to another. They were solving a phone-line engineering problem, but the model described human conversation so well that it became the foundation almost every communication framework since has borrowed from. People call it the “mother of all models” for a reason.

Here’s the idea in plain language:

  • Sender - the person with an idea. You, wanting to tell your team the deadline moved up.
  • Encoding - turning that fuzzy thought into words, tone, or images someone else can receive. You encode it as: “Heads up - the client moved the deadline to Friday.”
  • Message - the actual content that travels: the words, the slide, the voicemail.
  • Channel - the medium it travels through: face-to-face, a call, an email, a chat message.
  • Decoding - the receiver translating your words back into an idea in their own head, filtered through their assumptions, mood, and background knowledge.
  • Receiver - the person making meaning out of what arrived.
  • Feedback - their response flowing back to you: a nod, a reply, a confused look.
  • Noise - anything that distorts the message in transit. More on this below - it’s the part almost everyone underestimates.

Notice the important part: the idea in your head and the idea that lands in theirs are never the exact same thing. Communication isn’t a courier delivering a sealed box. It’s closer to a translation relay - your thought becomes symbols (words), the symbols travel, and the other person reconstructs their own version of your thought from those symbols alone.

Think of it like mailing flat-pack furniture instead of a finished chair. You disassemble your idea into parts (words) and pack instructions (tone, structure). The receiver has to assemble it themselves, using your instructions, their own tools (background knowledge), and whatever patience they have left that day. If a part is missing or the instructions are unclear, they build something different from what you had in mind.

That’s exactly what happened with “deprioritizing the mobile fix.” Same message, two rebuilt ideas - because decoding fills gaps with the listener’s own assumptions, not yours.

Noise: the three kinds of static that wreck a message

Shannon and Weaver used noise to describe anything that interferes with a message getting through cleanly. In human communication, that idea splits into three distinct types - and learning to name them fast is one of the most useful communication skills there is.

Physical noise is interference in the outside environment - the easiest kind to spot. Your mic keeps cutting out on a call, a jackhammer is running outside, the Wi-Fi lags and clips half your sentence. The audience missed words because of the room, not because your ideas were bad.

Psychological noise happens inside someone’s head - stress, distraction, anger, a preconception. Your manager reads your update right after a tense call with their own boss. They skim it, miss your caveat about a delay, and later act surprised - even though it was right there. Their internal state was the noise, not your writing.

Semantic noise comes from the words themselves - jargon, ambiguity, an acronym that means different things to different people. A finance lead tells a new hire, “we need to true this up before EOD, or the run-rate numbers will be off.” Three technical terms in one sentence. No stress, no distraction - just a vocabulary gap acting like static.

Type of noiseWhere it comes fromExample
PhysicalThe environmentBad signal, loud office, a slide too small to read
PsychologicalThe person’s state of mindDistraction, stress, defensiveness
SemanticThe words themselvesJargon, acronyms, vague pronouns

The mistake almost everyone makes is treating every miscommunication as a semantic problem - “I just need to explain it better” - when the real issue is psychological (they’re overwhelmed, not absorbing anything right now) or physical (they’re on spotty train Wi-Fi and missed half the call). Rewriting your message won’t fix a bad signal or a distracted mind. Before an important conversation, run a fast three-question check: is the room quiet enough? Is this person in the right headspace, or should it wait? Am I using words this specific person will understand?

The curse of knowledge: why experts explain things badly

Once you know something well, it becomes almost impossible to imagine not knowing it. Researchers call this the curse of knowledge - a term the brothers Chip and Dan Heath popularized in Made to Stick.

The clearest demonstration is a Stanford experiment. One person (the “tapper”) is given a well-known song and taps its rhythm on a table. Another person (the “listener”) has to guess the song from the tapping alone. Tappers predicted listeners would guess correctly about half the time. Listeners actually guessed correctly about 2.5% of the time - roughly 1 in 40. While tapping, the tapper can’t help but “hear” the full melody and lyrics in their head. To the listener, it’s just disconnected knocks. The tapper’s own knowledge made it nearly impossible to imagine the message without it.

It’s the same reason you can’t quite remember what it felt like to not know how to ride a bike. You can’t un-know the balance, so when you try to teach a child, you say “just find your balance” - advice that means nothing to someone who’s never felt it.

This is why senior engineers, doctors, and executives are often the worst people to explain their own field to a beginner - not because they don’t understand it, but because they understand it too well to remember what confusion feels like. A senior engineer tells a junior teammate, “just spin up a container and mount the volume, should take two minutes.” To the senior engineer, that genuinely is two minutes. To the junior teammate, three unfamiliar concepts just flew by, and a quick task turns into an hour of quiet, embarrassed struggling because they’re afraid to ask what “mount the volume” even means.

The fix isn’t to “dumb things down” - that phrase misses the point and is a little insulting besides. The fix is to deliberately rebuild the context you no longer notice you’re missing for the other person. Before explaining something you know well, ask: “what did I believe about this before I learned what I now know?” Then start there. And don’t trust a nod as proof of understanding - people nod to avoid looking slow, especially around a manager or a client. A specific question or a paraphrase closes the loop. A nod doesn’t.

One-way vs. two-way: why the feedback loop is everything

Look back at the model above. There’s an arrow running from receiver back to sender, labeled feedback. That arrow isn’t decoration - it’s the single feature separating communication that actually works from communication that just feels like it worked.

One-way communication travels from sender to receiver with no return path. A company memo with no way to ask questions. A lecture with no Q&A. The sender has no way of knowing whether the message landed correctly.

Two-way communication adds a return trip: a question, a paraphrase, a confused pause travels back to the sender, who can adjust in real time. A manager explains a new process and asks, “walk me through how you’d handle the first ticket that comes in” - and immediately hears whether it landed.

One-way is faster for the sender, which is exactly why it gets overused - emailing the whole team is quicker than checking each person understood. But speed for you is not accuracy for them. A CEO records a five-minute reorg announcement with no live Q&A. Employees privately reinterpret an ambiguous line - “some roles will evolve” - as “layoffs are coming,” and rumors spread faster than any follow-up correction can travel. The missing feedback loop didn’t just fail to help; it let a wrong meaning multiply unchecked.

End important messages with a feedback prompt that requires more than yes or no. “Does that make sense?” almost always gets a reflexive “yes.” Try “what’s your plan for the first step?” or “tell me back what you heard, in your own words.” And watch for the classic trap: confusing “I sent it” with “I communicated it.” A sent email is a one-way transmission until someone confirms what they understood. Most “I told you” / “I never heard that” arguments involve two people telling the truth - the message was sent, but the loop was never closed.

Choosing the right channel

The channel is the medium your message travels through - face-to-face, video, phone, chat, email. In the 1980s, researchers Richard Daft and Robert Lengel developed media richness theory to explain why the same message succeeds in one channel and fails in another completely. Some channels are “rich” - they carry tone, facial expression, pacing, and instant back-and-forth. Others are “lean” - mostly bare text, with feedback delayed or absent.

The practical rule: match the channel’s richness to the message’s complexity and emotional weight.

SituationBest-fit channelWhy
Confirming a meeting timeChat or emailSimple, unambiguous; speed beats richness
Giving critical feedbackIn-person or videoHigh emotional stakes; tone prevents misreading
Negotiating a contract detailPhone or videoAmbiguous, needs fast back-and-forth
Announcing a policy to 500 peopleWritten memo + live Q&ANeeds a precise record, plus a rich channel for questions

A manager needs to tell a direct report their project was cancelled. Sent as a two-line email, it reads cold and dismissive, even without that intent - there’s no tone to soften it and no room to ask “what does this mean for me?” On a short call instead, the same news comes with a calmer tone and space for the employee’s immediate question, and a visible sense the manager isn’t hiding behind text.

Before you hit send, ask two questions: how ambiguous or emotionally loaded is this, and how much real-time feedback will I need to get it right? The higher the answer to either, the richer your channel should be.

Common misconceptions

  • “We have a communication problem” is a real diagnosis. It isn’t - it’s a symptom. The model gives you six specific checkpoints (idea, encoding, channel, noise, decoding, feedback) instead of one vague complaint.
  • If I explain it more, they’ll get it. Not if the real problem is psychological or physical noise. A distracted or overwhelmed listener doesn’t need better wording - they need a different time or place.
  • A nod means they understood. Nodding is social behavior, not feedback. It closes nothing.
  • Sending a message is the same as communicating it. It’s only one-way transmission until the loop closes with a question, a paraphrase, or a visible action that matches what you meant.
  • Email is always fine because it’s convenient. Convenient for the sender isn’t the same as clear for the receiver. Convenience is a terrible reason to pick a lean channel for a message that’s ambiguous or sensitive.

How to use this

  1. Diagnose before you fix. Next time a message lands wrong, run it through the checklist: was the idea itself unclear, was it poorly encoded, was the channel wrong, was there noise, did decoding go sideways, or was there no feedback loop? Fix that one part.
  2. Run the three-question noise check before anything important. Is the environment quiet? Is the other person in the right headspace right now? Are these words this specific person will understand?
  3. Ask what you believed before you knew what you know now. Start explanations there - with concrete examples and stories, not expert shorthand.
  4. Build a real feedback prompt into every important message. Replace “does that make sense?” with “what’s your first step?” or “tell me back what you heard.”
  5. Match richness to stakes. Lean channels for simple facts. Rich channels (call, video, in-person) for anything ambiguous, complex, or emotionally loaded.

Conclusion

The single idea worth keeping: communication is never a transfer, it’s a rebuild. Your listener doesn’t receive your thought - they reconstruct their own version of it from the words you gave them, filtered through noise, their own knowledge, and whatever else is going on in their head. Most miscommunication isn’t a mystery once you see it this way - it’s a specific, nameable break in one of six links, and every link can be checked and repaired.

Understanding how a message can go wrong is only half the job. The other half is why people believe what they hear at all - which is where persuasion enters the picture, built on three levers that are far older than Shannon’s model and just as easy to misuse.

Frequently asked questions

What is the sender-receiver model of communication?

It's a framework that breaks communication into steps - a sender encodes an idea into a message, sends it through a channel, and a receiver decodes it back into meaning, then sends feedback. It comes from Claude Shannon and Warren Weaver's 1948 model and underlies almost every communication theory since.

What is noise in communication?

Noise is anything that distorts a message between sender and receiver. There are three kinds - physical (the environment, like a bad connection), psychological (the receiver's state of mind, like stress or distraction), and semantic (confusing words, jargon, or ambiguous language).

What is the curse of knowledge?

It's the difficulty experts have imagining what it's like not to know something they know well. It makes them skip steps, use shorthand, and assume shared context that a less experienced listener doesn't have.

Why does feedback matter so much in communication?

Because sending a message is not the same as being understood. Without feedback - a question, a paraphrase, a confused look - the sender has no way to know a message landed wrong until the mistake shows up later as a missed deadline or a damaged relationship.

How do I know which communication channel to use?

Match the channel's richness to the message. Simple, factual updates are fine over email or chat. Anything ambiguous, complex, or emotionally sensitive - like tough feedback or a negotiation - needs a richer channel like a call or face-to-face conversation, because it benefits from tone and real-time feedback.

Why do smart, articulate people still get misunderstood?

Usually because of the curse of knowledge, not a lack of clarity. Once you know something well, you forget what confusion feels like, so you explain at your own level of understanding instead of the listener's.

Continue reading

Related topics