4 min read

The Best Engineers I Know Are Great Communicators

Technical skill gets you in the door, but clear communication is what separates good engineers from truly great ones. Here's what I've learned about the underrated superpower of engineering leadership.

B
Brian Hardin
Career Leadership Engineering Culture Communication

The Best Engineers I Know Are Great Communicators

Early in my career, I believed the path to becoming a great engineer was purely technical. Read more docs. Learn another language. Master the framework. Ship faster.

I wasn't wrong — but I was incomplete.

The engineers who have had the biggest impact on teams I've worked with weren't always the ones who wrote the cleverest code. They were the ones who could explain what they built, why they built it that way, and what trade-offs they considered along the way.

Code Is Communication

We talk about "clean code" and "readable code" as if readability is a nice-to-have. It's not. Your code is read far more often than it's written. Every function name, every abstraction, every commit message is a tiny act of communication with your future self and your teammates.

Consider these two approaches:

# Approach A
def proc(d):
    return {k: v for k, v in d.items() if v > 0}

# Approach B
def filter_positive_values(data: dict) -> dict:
    return {key: value for key, value in data.items() if value > 0}

They do the same thing. But Approach B communicates intent. Six months from now, nobody has to guess what proc was supposed to do.

This extends beyond variable names. Architecture decisions, pull request descriptions, and even Slack messages are all part of the communication layer that makes engineering teams function.

The Senior Engineer's Real Job

There's a moment in every engineer's career where the job quietly shifts. You stop being evaluated primarily on what you can build and start being evaluated on what you can enable others to build.

That shift is almost entirely about communication:

  • Writing clear RFCs so the team can align before a single line of code is written
  • Giving constructive code reviews that teach rather than just gatekeep
  • Translating technical constraints into language that product managers and designers can act on
  • Documenting decisions so the next person doesn't have to reverse-engineer your thought process

I've watched engineers with incredible technical depth get passed over for leadership roles because they couldn't articulate their ideas in a meeting. And I've watched mid-level engineers accelerate their careers because they could write a design doc that got an entire team rowing in the same direction.

Writing Is Thinking

One of the most valuable habits I've developed is writing things down before I start building. Not formal documentation — just thinking on paper.

A rough outline of the approach. A list of open questions. A quick sketch of the data flow.

This isn't overhead. It's the work. Writing forces you to confront the gaps in your understanding. It's easy to think you have a plan when it's all in your head. It's much harder to maintain that illusion when you try to put it into sentences.

"Writing is nature's way of letting you know how sloppy your thinking is."
— Dick Guindon

If you can't explain your approach in a few paragraphs, you probably don't understand it well enough yet. That's not a failure — that's the process working.

Practical Ways to Level Up

If you're an engineer who wants to get better at communication, here's what's worked for me:

1. Write More Pull Request Descriptions

Don't just describe what changed. Describe why it changed and what you considered before landing on this approach. Your reviewers will give better feedback, and your future self will thank you when you're reading git log six months later.

2. Volunteer to Write the Design Doc

Nothing sharpens your communication skills like trying to get a room full of engineers to agree on an approach. Design docs force you to anticipate questions, address concerns proactively, and structure your argument clearly.

3. Explain Technical Concepts to Non-Technical People

This is a skill, and it improves with practice. The constraint of avoiding jargon forces you to truly understand what you're talking about. If you can explain database indexing to a product manager using a library analogy, you understand indexing better than someone who can only describe it in technical terms.

4. Read Your Messages Before You Send Them

This sounds obvious, but it's remarkable how often we fire off a Slack message or email without re-reading it. Take five seconds. Is it clear? Could it be misread? Does it actually answer the question that was asked?

The Compound Effect

Communication skills compound over time in a way that's hard to appreciate in the moment.

The engineer who writes clear docs builds trust. Trust leads to autonomy. Autonomy leads to bigger projects. Bigger projects lead to more impact. More impact leads to career growth.

It's not a straight line, but the pattern is consistent. The engineers who can articulate their value — to their team, to their manager, to the broader organization — are the ones who get the opportunities to do the most meaningful work.

The Bottom Line

Technical excellence matters. I'm not arguing otherwise. But if you're looking for the highest-leverage skill to develop in your engineering career, I'd point you toward communication every time.

Learn to write clearly. Learn to speak concisely. Learn to listen actively.

The code you write will eventually be rewritten. The trust and clarity you build with the people around you will carry forward for your entire career.

Related Posts