Communication Skills for Engineers

Communication is part of the engineering job, not a decorative soft skill. The current ABET engineering accreditation criteria require graduates to be able to communicate effectively with a range of audiences. That is the useful frame: the same design decision needs a different explanation for another engineer, a product manager, an executive, or a customer.

This is often a translation problem rather than a lack of technical knowledge. The useful question is how to convert expert context into a decision-ready explanation for a mixed room. If you are working on becoming more articulate in general, that guide covers the foundations. This one focuses on recurring technical-communication constraints.

Why Does Knowing More Make You Worse at Explaining?

In 1989, economists Colin Camerer, George Loewenstein, and Martin Weber described the curse of knowledge: people who know more can struggle to ignore their private information when predicting what a less-informed person will understand. That does not mean experts are doomed to explain badly. It means an explanation needs an explicit audience model.

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 faster, and the session-timeout issue behind repeated support tickets is fixed" is the public API. Put measured speed and ticket counts behind that headline when the audience needs the evidence.

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.

Spontaneous answers compete for limited working-memory capacity: you are choosing a position, retrieving evidence, planning words, and tracking the room at once. Nelson Cowan's review argues for a central capacity of about four chunks under constrained conditions, although capacity depends on the task and what counts as a chunk. A short structure reduces how much you have to organize live.

Precision matters in technical work, so it can feel safer to wait until every caveat is resolved. In meetings, a provisional answer can be more useful: "My current view is X; the uncertainty is Y." On global engineering teams, this can require extra processing for anyone building speaking confidence as a non-native English speaker; extra formulation time is not weaker engineering judgment.

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 view on that -- let me frame it." This signals that you are about to contribute and gives you a brief planning beat.

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 can build a starting mental model, but the analogy has to come from the listener's world and its limits should be named. "It's like a git merge conflict" only works if your listener uses git. "It is like two people editing the same document at the same time; the analogy breaks down when we discuss failure recovery" is both accessible and honest.

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?

ABET makes communication with different audiences an explicit engineering outcome. In practice, the need becomes more visible as engineers write design documents, lead reviews, explain risk, mentor teammates, and influence priorities. A technically correct presentation still fails if the audience cannot identify the decision it needs to make.

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:

1. What changed? (The result, the decision, the recommendation -- stated first.)
2. Why does it matter? (The impact on something the audience cares about -- revenue, reliability, user experience, timeline.)
3. 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.

Articulated's AI speech coach can support the recorded part of this loop. Freestyle, Speed Breakdown, and Scenario Practice let you record one spoken attempt, then review six-skill feedback, Key Moments, transcript-based rewrites, and session history. It does not recreate a stakeholder's questions or a live design review, so use private reps to prepare and real meetings to test transfer.

Which Engineering Habits Transfer to Communication?

Some habits from technical work can be reused in communication practice.

Precision under constraints. Apply precision to the decision and tradeoff before the implementation detail. That produces a concise headline without discarding the technical evidence.

Systems thinking. If you already map how parts connect to wholes, reuse that habit to structure an explanation: headline, dependencies, tradeoff, consequence. The six skills of effective communication provide another way to inspect the result.

Feedback loops. Treat a recording as test output: choose one observable defect, change one input, and compare another attempt. The same method can support building speaking confidence without turning a single score into a judgment of ability.

The gap is not between "technical people" and "good communicators." It is between a detailed internal model and an explanation designed for a particular listener. Treating that translation as an engineering constraint makes it easier to practice deliberately.

Sources and Limits

• ABET 2025-2026 criteria for accrediting engineering programs establishes communication with a range of audiences as a student outcome; it does not measure promotion speed or workplace performance.
• Camerer, Loewenstein, and Weber's original curse-of-knowledge paper studies belief prediction in economic settings. Applying it to technical explanations is a practical inference.
• Cowan's working-memory review supports a constrained-capacity model, not a universal four-item rule for every speaker or task.

Keep Reading

• How to speak up in meetings when you are the quiet one
• How to give tough feedback without being a jerk
• How to think faster when speaking (so you stop losing your train of thought)
• Public speaking tips for introverts
• How to stop blanking mid-sentence