Communication Skills for Engineers: Why Smart People Struggle to Be Understood

A LinkedIn analysis of over 4 million professionals found that employees who listed communication as a skill were promoted 11% faster than those who didn't. For engineers specifically, communication topped the list of most in-demand soft skills for the second consecutive year. Yet ask most engineers where they feel least competent, and the answer isn't a programming language or a system design pattern. It's the meeting where they couldn't explain why a technical decision matters.

This isn't a confidence problem. It's a translation problem. And the standard advice -- "just simplify it" or "know your audience" -- is about as useful as telling someone to "just write better code." The real question is why technical minds systematically struggle with verbal communication, and what specific mental models actually fix it. If you're working on becoming more articulate in general, that guide covers the foundations. This one is about the problems unique to technical brains.

Why Does Knowing More Make You Worse at Explaining?

In 1989, economists Colin Camerer, George Loewenstein, and Martin Weber published a study in the Journal of Political Economy that named a cognitive bias most engineers experience daily but can't identify: the curse of knowledge. Once you understand something, you literally cannot reconstruct what it's like to not understand it. Your brain has no "undo" button for comprehension.

Elizabeth Newton demonstrated this viscerally in her 1990 Stanford dissertation. She asked people to tap the rhythm of well-known songs on a table while listeners tried to guess the song. Tappers predicted listeners would guess correctly 50% of the time. The actual success rate? 2.5%. The tappers could hear the music in their heads while tapping. They couldn't fathom that listeners heard only random knocking.

This is you in a sprint review. You've spent two weeks deep inside a system. You understand the trade-offs, the edge cases, the architectural reasoning. When you explain your decisions, you're tapping a song. Your product manager hears knocking.

The curse of knowledge is worse for engineers than for most professionals because the knowledge gap is wider. The distance between "I understand distributed consensus algorithms" and "I have no idea what you just said" is enormous. And the curse scales with depth -- the more expert you become, the harder it gets to bridge back.

What's the Real Reason You Default to Implementation Details?

Watch an engineer answer "how's the project going?" in a stakeholder meeting. Nine times out of ten, they start with what they did -- the API they refactored, the race condition they solved, the database migration they ran. They describe the work, not the outcome.

This isn't ego. It's how technical brains organize information. When you spend your days debugging, your mental model of a project is the implementation. Asking you to skip to outcomes is like asking you to describe a building by starting with the view from the penthouse when your mental model starts at the foundation.

The fix isn't "talk about outcomes, not implementation." That advice describes the destination without giving you a route. Instead, use what I'll call the API pattern: think of every explanation as an interface you're designing.

An API has a public surface and private internals. The caller doesn't need to know how the function works internally. They need to know: what does it accept, what does it return, and when should they use it?

Apply this to any explanation:

What it accepts = what was the situation or problem?
What it returns = what's the result or recommendation?
When to use it = why should the listener care?

"We refactored the authentication service to use JWT tokens instead of session-based auth, which involved migrating the middleware layer and updating seventeen endpoints" is internals.

"Login is now 3x faster and we eliminated the session timeout bug that was causing 200 support tickets a month" is the public API.

Same work. Completely different signal to the listener. If you find yourself rambling through technical details in these moments, that guide has specific frameworks for cutting yourself off.

Why Are Meetings So Hard for People Who Think Deeply?

Here's a pattern most engineers recognize: someone asks a question in a meeting. While you're still processing the question -- considering edge cases, formulating a precise answer -- three other people have already responded. By the time you have something worth saying, the conversation has moved on.

This isn't slowness. It's a working memory allocation problem.

Research on cognitive load and dual-task processing, rooted in Daniel Kahneman's model of limited attentional capacity, shows that the brain draws from a single pool of cognitive resources. When you're deeply processing a complex question and simultaneously monitoring a conversation for the right moment to speak, both tasks degrade. Your processing gets shallower, or your conversational timing gets worse.

Engineers tend to allocate disproportionately toward processing because precision matters in technical work. Getting an answer 80% right feels worse to a technical mind than staying silent. But in meetings, an 80% answer delivered at the right moment is worth more than a 100% answer delivered two topics late.

Two shifts that help:

Pre-load your positions. Before a meeting, spend five minutes writing down your stance on each agenda item. Two sentences max per item. You're not scripting -- you're reducing the real-time cognitive load so you have working memory available for the conversation itself. This is the same principle behind thinking faster when speaking.

Claim space verbally, then fill it. When a question is asked and you need processing time, say: "I have a thought on that -- give me a second." This is a verbal placeholder. It signals you're about to contribute, buys you three to five seconds, and prevents the conversation from moving on. It feels awkward exactly once. Then it becomes natural.

Is Being Good in Slack Actually Hurting You?

Many engineers are genuinely excellent written communicators. They write clear documentation, thoughtful code reviews, and precise Slack messages. Then they step into a meeting room and it falls apart.

This gap makes sense when you understand what writing gives you that speaking doesn't: edit time. In Slack, you compose a thought, re-read it, restructure it, delete the parts that don't work, then hit send. The person reading it sees a polished final product. In conversation, you're shipping your first draft live.

The problem isn't that you're bad at communicating. It's that you've unconsciously optimized for a medium that gives you a revision pass, and you haven't built equivalent skills for the medium that doesn't.

This creates a secondary problem: because you're articulate in writing, people assume you're equally comfortable speaking. When you stumble verbally, the gap between their expectation and your delivery is more jarring than if you'd never demonstrated written fluency at all.

The bridge between written and verbal fluency is structured improvisation. Not scripting (too rigid), not winging it (your current approach). Instead:

Outline, don't draft. Before you speak, identify your headline and two supporting points. Not sentences -- concepts. Then generate the language in real time. This is how good speakers work: they know their skeleton, not their script.
Practice the transition out loud. Take a complex technical topic and explain it to an empty room for sixty seconds. Do this daily. The goal isn't content mastery (you already have that). The goal is building the neural pathways between knowing and saying without the intermediary step of writing.

For introverts especially, the shift from written to verbal can feel like losing a superpower. It's worth reading about public speaking strategies for introverts to understand why this transition is harder and what specifically to practice.

The Feynman Compiler: A Framework for Technical Explanations

Richard Feynman could explain quantum electrodynamics to a room of non-physicists. Not because he dumbed it down, but because he genuinely understood which parts of the concept were load-bearing and which were scaffolding.

Most engineers do the opposite when simplifying. They strip out the terminology but keep the structure of their expert-level understanding. The result is a technically accurate explanation that's still incomprehensible because it follows a logic path that only makes sense if you already understand the domain.

Think of it like a compiler. Your expert understanding is the source code. A non-technical explanation isn't a different syntax for the same code. It's a different program -- written for a different machine (the listener's mental model), optimized for different constraints (conceptual understanding vs. technical precision).

The Feynman Compiler has three steps:

1. Identify the one thing. Every technical concept has a single core insight that everything else hangs on. For distributed systems, it might be: "Multiple computers need to agree on the truth, and messages between them can get lost." Everything else -- Paxos, Raft, Byzantine fault tolerance -- is elaboration. Find the one thing.

2. Anchor to something familiar. Analogies aren't decoration. They're the fastest way to build a mental model from scratch. But the analogy has to come from the listener's world, not yours. "It's like a git merge conflict" only works if your listener uses git. "It's like two people editing the same document at the same time and their changes contradicting each other" works for anyone.

3. Declare your simplification. Say out loud: "I'm simplifying here, but the key idea is..." This does two things. It signals intellectual honesty (you're not pretending the topic is actually simple). And it gives you permission to omit the caveats and edge cases that your technical brain wants to include but that would drown the listener.

How Do You Give Technical Presentations That Don't Lose the Room?

Jon Leydens' research published in IEEE Transactions on Professional Communication found that engineers in senior roles spend 70-95% of their workday on communication tasks, up from roughly 30% early in their careers. The ability to present technical material clearly isn't a nice-to-have. It's the difference between staying an individual contributor and moving into roles where you shape technical direction.

The most common mistake in technical presentations: organizing by how you discovered the information instead of by what the audience needs to understand.

Your discovery process: "I investigated X, then tried Y, then realized Z, which led me to A." Logical. Chronological. Also terrible for the audience, because they don't know why they should care about X until they understand A.

Restructure every technical presentation around three questions:

What changed? (The result, the decision, the recommendation -- stated first.)
Why does it matter? (The impact on something the audience cares about -- revenue, reliability, user experience, timeline.)
What's the evidence? (The technical detail, available for questions, not the main event.)

This is an inverted pyramid, and it works for the same reason it works in journalism: the most important information comes first, and the audience can opt into as much detail as they want.

If filler words are undermining your credibility during presentations, that's a separate but fixable problem. The key insight: fillers spike when you're searching for the next point, which is why having a clear structure reduces them automatically.

The Debug Loop for Communication

Engineers improve technical skills through a specific loop: write code, run it, observe the output, identify the bug, fix it, repeat. You can apply the same loop to communication.

1. Capture the output. Record yourself explaining a technical concept (your phone's voice memo app works fine). This is your stdout.

2. Run the tests. Listen back with specific checks:

Did you state the conclusion first, or bury it?
Could a non-engineer follow the logic?
Where did you use jargon without defining it?
How many filler words in sixty seconds?

3. Identify the bug. Pick the single most impactful issue. Not all of them -- one. This is your sprint focus.

4. Fix and re-deploy. Practice the same explanation again with the fix applied. Record again. Compare.

5. Regression test. In your next real conversation, focus on that one fix. Did it hold under live conditions, or did old patterns reassert?

This loop works because it matches how your brain already approaches skill development. You don't need a fundamentally new learning process. You need to apply your existing one to a new domain.

Tools like Articulated are built around this exact loop -- you practice explaining technical concepts in realistic workplace scenarios, get specific feedback on structure and clarity, and track which patterns you're fixing over time. Think of it as a linter for your speaking, catching the issues you can't spot in real time.

What's the Non-Obvious Advantage Engineers Have?

Here's something the "communication for engineers" content never mentions: your technical training has already given you several communication superpowers. You just haven't recognized them as transferable.

Precision under constraints. You're trained to be exact with limited resources. Applied to communication, this means you're naturally suited to concise, high-signal speaking. The problem isn't that you lack the skill -- it's that you apply precision to the wrong layer (technical details instead of outcomes).

Systems thinking. You see how parts connect to wholes. This makes you better at structuring complex explanations than someone who thinks linearly -- once you learn to use that skill consciously in communication. The seven dimensions of effective communication map well to a systems-thinking approach.

Comfort with feedback loops. Most people resist recording themselves or getting direct feedback on their speaking. You're already wired to treat feedback as data, not judgment. That's a genuine advantage in building speaking confidence faster than average.

The gap isn't between "technical people" and "good communicators." It's between unconscious competence in one medium and conscious incompetence in another. You've closed that gap before -- every time you learned a new language, framework, or paradigm. This is the same process with different syntax.