How You Say It Matters: Communication as an Engineering Skill

Two engineers can raise the exact same concern in a meeting and get opposite reactions. One gets brushed off. The other gets the roadmap changed. The difference usually isn't who was more correct — it's how the point was delivered. Engineers spend years training the "what" of their skill set and almost no time on the "how," even though the how is often what determines whether the what ever gets acted on.

The message isn't just the content

A technically accurate point, delivered badly, functions the same as a wrong point in a room — it gets ignored. A few patterns that quietly sink good input:

• Leading with the problem, not the impact. "The auth service has a race condition" gets a shrug. "Under load, about 1 in 200 logins could silently fail, and we won't see it in staging" gets attention, because it answers the question the listener actually has: does this matter to me, right now.
• Framing feedback as a personal critique instead of a shared problem. "You should have caught this in review" puts someone on the defensive before they can hear the actual issue. "This slipped past review — should we add a check for it?" gets the same concern raised without triggering a defense reflex.
• Burying the ask. A message that ends with three paragraphs of context and no clear question leaves the reader to guess what you need from them. State the ask first, then the context that supports it.

Calibrating to the audience

The same information needs a different shape depending on who's receiving it, and getting that wrong is one of the most common ways technical communication fails:

• To another engineer, the mechanism matters — what's actually broken and why.
• To a manager, the impact and options matter more than the mechanism — what does this cost, and what are the choices.
• To a non-technical stakeholder, the analogy matters more than either — what's the closest thing in their world this compares to.

Explaining a database index the same way to all three audiences means two of them tune out, not because they don't care, but because you handed them the wrong layer of detail for the decision they're actually trying to make.

Tone under disagreement

The moment communication skill matters most is exactly the moment it's hardest to apply — when you disagree with someone senior, or when you're the one who made the mistake being discussed. The instinct is either to go quiet (and let a bad decision stand) or to get defensive (and make the conversation about ego instead of the problem). Neither serves the work.

The version that actually works is boring: state the disagreement plainly, attach it to a concrete consequence, and make it easy for the other person to change course without losing face. "I think this breaks under load — can we timebox a spike to confirm before we commit to the date?" does more work than either silence or "this won't work."

Practicing it like a skill, not a trait

Communication style feels like a fixed personality trait, but it's closer to a habit you can deliberately rebuild:

• Read your own messages back before sending, specifically checking: does this lead with what the reader needs to know?
• After a meeting where a point of yours didn't land, ask why — not to relitigate it, but to notice the gap between what you meant and what was heard.
• Watch how the people whose input consistently gets acted on phrase things, and notice what they're doing differently from you.

The technical judgment was never the bottleneck for most engineers. Getting that judgment into someone else's head, intact, is the skill that decides whether it changes anything.