Communication tops the list of soft skills researchers measure in software engineering, ahead of teamwork, ahead of analytical ability, ahead of any other trait. It's the single most-studied quality of a good developer, and it has almost nothing to do with writing code.
So the meeting where an engineer has to explain a system to people who don't code isn't a soft edge of the job. That meeting is the job. The developers who compound over a career are the ones who make good decisions in that room: what to say, what to cut, what to push back on. The rest is craft you can practice.
Decide Whether You're Translating or Persuading
Every meeting with non-engineers is one of two things, and you have to know which before you open your mouth. If the group has already decided to do the work and needs to understand what you're building, you're translating. If the group hasn't decided, or is leaning the wrong way, you're persuading. Two different jobs.
Translating rewards patience. You slow down, define terms, and let the room ask the obvious questions without punishing them for it.
Persuading rewards structure. Lead with the decision you want made, then the two or three reasons it holds, then the risks of the alternative. Engineers lose rooms by confusing the two: showing up to persuade with a tutorial, or showing up to teach with a sales pitch.
A useful tell: if the highest-ranking person in the room can't restate your recommendation in one sentence after ten minutes, you were persuading and you did it wrong. Some of the sharpest guidance on this split, including plain writing, concrete detail, and short sentences, sits in a Harvard Business Review piece on how technical experts tell stories. Worth reading before your next steering committee. It overlaps with Designbeep's advice for developers who want to stand out: clarity, not vocabulary, is what people remember.
Decide How Much Jargon You're Willing to Spend
Jargon isn't free. Every acronym you use costs the listener a small amount of attention, and once the budget is gone they stop trying. Unfamiliar technical language also tends to make the listener more resistant to whatever you're proposing, not less. Heavy jargon can reduce persuasion and raise the listener's perception of risk, even when the underlying idea is sound.
So spend the budget deliberately. A few options, in rough order of cost:
- Drop the term entirely. If you can describe the thing in plain words in under a sentence, do that and skip the name. Nobody needs to hear "idempotent" when "safe to run twice" gets the point across.
- Name it once, define it once. If the term will recur, introduce it with a one-line definition the first time and then use it. Cheaper than re-explaining it four meetings from now.
- Use the analogy, keep the term. For load-bearing concepts like a queue, a cache, or a rollback, reach for a concrete comparison the room already knows. Guides for developers, including the Stanford Online overview on communicating technical ideas, are unanimous on this: analogies do most of the work.
Decide Which Habits You'll Repeat for a Decade
The developers who get meaningfully better over ten years aren't the ones who learned the most frameworks. They're the ones who picked a handful of habits early and kept doing them when nobody was watching. A short list worth stealing:
- Read the ticket twice. Once for what it says, once for what it's asking. The second read is where you catch the requirement nobody wrote down.
- Write the summary before the code. A two-sentence description of what you're about to build, in plain language, will save you a day of rework more often than any test suite.
- Leave the file a little better than you found it. A rename, a deleted dead branch, a comment that explains the weird thing. Small, boring, compounding, and nothing like a rewrite.
- Ask one dumb question per meeting. You are almost never the only person who didn't follow. The junior engineer in the corner will thank you silently.
None of this is glamorous, and none of it shows up in a job description. But it's what the strongest engineers do consistently, and it beats any framework tutorial you'll read this year. The person who talks clearly, reviews carefully, and picks habits that compound is the one still gaining ground a decade in, while everyone chasing the newest tool is starting over.
