There’s a version of an engineer that is technically exceptional and almost invisible. They ship solid work, fix hard bugs, know the systems deeply — and somehow stay in the same role for years while others with similar (or lesser) technical skills move up. The gap is almost always communication.
This isn’t a comfortable thing to say, and it’s even less comfortable to hear. But after watching it play out enough times — in myself, in teammates, in people I’ve mentored — the pattern is too consistent to ignore. The engineers who grow fastest are not always the best coders. They’re the ones who can make their work legible to the people around them.
What “Communication” Actually Means Here
It’s not public speaking. It’s not being extroverted. It’s not performing confidence you don’t feel.
It’s a more specific set of skills:
- Explaining a technical decision to someone who won’t read the code — your manager, a product owner, a client
- Writing a postmortem that actually improves the system — not a timeline of events, but an honest analysis of what failed and why
- Asking a question in a way that gets a useful answer — providing context, stating what you’ve already tried, naming the actual question
- Documenting a system so your future self (and your teammates) can understand it — not just what it does, but why it’s built that way
- Disagreeing in a meeting without creating friction — making your case clearly and then accepting the decision
None of these are personality traits. They’re learnable skills, and most engineering education doesn’t teach them at all.
The Moment It Becomes Obvious
Every engineer hits a point where the job changes shape. Early on, your output is code. Your quality is measured by what ships and what breaks. Communication matters, but mostly just enough to function as part of a team.
Then something shifts. Maybe you get a few years in. Maybe you get promoted to a senior role. Suddenly the job is no longer just writing good code — it’s influencing what gets built, when, and how. You’re in rooms where decisions get made. You’re expected to have opinions and to express them in ways that move things forward.
And here’s where engineers who haven’t developed communication skills stall. They have good instincts but can’t translate them into arguments that land with non-technical stakeholders. They write technically correct designs that nobody reads. They raise concerns in ways that sound like complaints. Their influence doesn’t match their expertise.
I’ve been in that position. The turning point for me was recognizing that explaining things well wasn’t dumbing them down — it was a separate skill that required its own practice.
The Highest-Leverage Communication Skill: Writing
If I could develop one communication skill first, it would be written communication. For engineers specifically, writing is how you project influence at scale.
A well-written architecture decision record stays in the codebase for years. A clear runbook saves your team hours during incidents. A concise Slack message that gives enough context gets answered; a vague one generates a thread of clarifying questions. A good postmortem changes how your team thinks about failure. A technical blog post — even an internal one — reaches people who weren’t in the room.
The mechanics of good engineering writing are not complicated:
- State the conclusion first. Don’t make people read to the end to find out what you’re proposing. Start with the answer; use the body to justify it.
- Separate what from why. What you built or decided is usually obvious from the code. Why you made that choice — the constraints, the alternatives considered, the trade-offs accepted — is what gets lost without documentation.
- Write for someone who wasn’t there. The mental model you have right now, fresh from the work, is the most complete it will ever be. Your job is to put enough of it on paper that someone six months from now can reconstruct the reasoning.
- Revise. The first draft is never the right length. Cut it until every sentence earns its place.
Explaining Complexity Without Losing Accuracy
The anxiety most engineers have about communicating with non-technical people is that simplifying means lying. If you strip out the nuance, you’re giving someone a false picture of how the system works, and then they’ll make bad decisions based on it.
This is real, but it’s not a reason to avoid simplification — it’s a constraint on how to do it well.
The goal isn’t to make everything sound easy. The goal is to convey the right level of detail for the decision being made. An executive deciding whether to invest in a migration needs to understand the risk and the benefit, not the implementation details. A product manager prioritizing a bug fix needs to understand the user impact and the fix complexity, not the root cause in the memory allocator.
The frame I use: what does this person need to understand in order to make a good decision? That determines what to include and what to leave out. It’s not dumbing down — it’s editing for the audience.
When the details matter, say so explicitly. “This decision has a subtlety that I want to make sure doesn’t get lost” signals that you’re being careful, not that you’re hiding complexity.
Disagreeing Well
Disagreement is where a lot of engineering communication goes wrong. The technical instinct is to be right — to assemble the evidence, make the argument, win. But in a team setting, being right isn’t enough. How you disagree determines whether your input is trusted.
A few things that actually work:
Disagree in private before disagreeing in public. If you have concerns about a plan, raise them with the decision-maker before the all-hands meeting where the plan gets announced. You get a more receptive audience, and you avoid the dynamic of publicly challenging someone’s decision.
Name what you agree with before you push back. “I think the overall direction makes sense, and I want to flag something about the timeline” is a very different entry point than “the timeline is unrealistic.” Both might be saying the same thing, but one keeps the conversation open.
Distinguish between “I wouldn’t do this” and “this is a bad decision.” Lots of engineering decisions are defensible in multiple ways. Your preference isn’t always the right default.
Commit once the decision is made. Disagree and commit is a real thing. Continuing to relitigate a settled decision in how you talk about it — even subtly — erodes trust faster than the original disagreement would have.
How to Actually Get Better
Communication is a skill, which means it improves with practice and feedback. A few things that have worked for me:
Write more. Keep a work journal. Write up the thing you just debugged. Write down the decision you just made and why. It doesn’t have to go anywhere — the act of putting it in words is the practice.
Present at team meetings. Even a five-minute walkthrough of something you built forces you to think about what matters and what to leave out. The smaller the audience, the lower the stakes. Start there.
Ask for feedback on your writing. Send a doc to someone you trust and ask “is this clear?” Not “is it good?” — is it clear. You want to know what they understood, not what they thought of it.
Read writing you admire. The clearest technical writers share identifiable patterns: short sentences, active voice, concrete examples, conclusions up front. Reading deliberately teaches you to notice those patterns.
Pay attention to what questions you get asked. If people consistently ask you to clarify the same kinds of things, that’s signal. You’re leaving something out that your audience needs.
The Actual Differentiator
Senior engineers don’t stop writing code. They just add a second job to it: making sure the right people understand what they’re building, why it matters, and what it would take to do it well.
The engineers who can do both — ship quality work and make it legible — are genuinely rare. More rare than engineers who are only technically strong, because technical skills get developed through deliberate educational pipelines. Communication skills mostly don’t.
Which means the gap is real, the opportunity is real, and the path to closing it is more straightforward than most people think. Write more. Explain things. Ask if it landed. Adjust. Repeat.
That’s the whole practice.