How to Talk to Humans

Why Your Best Code Won't Matter If You Can't Explain It

I spent two years watching brilliant engineers tank career conversations. Not because they weren't smart. Because they tried to translate their intelligence directly into words, and somewhere between their brain and the other person's ear, everything got scrambled.

One of them built a system that cut database query time by 68%. He got into a room with a non-technical stakeholder to pitch for resources. Thirty seconds in, he was deep in indexing strategy. The stakeholder checked out. The project didn't get funded.

Here's what happened: he was speaking to someone else's context, not the person in front of him.

The gap between knowing something and being able to explain it to a human who doesn't share your frame of reference is not a soft skill. It's a hard constraint on how far your work travels. It affects whether your ideas get adopted. Whether you get promoted. Whether you can influence decisions that matter. Whether anyone actually understands what you built and why it matters.

Most engineers I've worked with treat communication like a tax on "real work." You finish the thing, then you have to go explain it to people who don't get it. Tolerate their questions. Try not to be frustrated that they need it spelled out.

That's backward.

Explaining something to someone who doesn't speak your language is a skill. A learnable one. Not something you're born with or not. It's not about dumbing anything down. It's about meeting someone in their world first, building a shared understanding, then moving together toward the technical reality.

The difference between a mediocre explanation and one that sticks is usually this: you stopped assuming what the other person knows, and you started assuming what they care about. You built a bridge from their problem to your solution instead of just describing the solution and hoping they could figure out the bridge on their own.

I wrote "How to Talk to Humans" because I kept seeing the same pattern across teams. Engineers who could architect systems that scale to millions of requests, but couldn't articulate to their manager why that architecture mattered. Product people who understood the feature but couldn't explain it to customers in a way that made sense. Leaders who had the right strategy but couldn't bring people along because the words didn't land.

The book is built on one core idea: communication is not decoration on top of competence. It's a tool that makes your competence visible, transferable, and valuable to other people. And like any tool, it has techniques.

The chapters walk through real scenarios. How to explain something technical to someone non-technical without losing precision. How to listen for what someone actually needs to hear, not what you think they should know. How to move a conversation from confusion to clarity without sounding like you're simplifying. How to know when you're speaking and when you should shut up and listen.

None of this is theory. It's all grounded in conversations that actually happened, mistakes I watched happen, and what changed when people started thinking about communication the way they think about code: as a problem to solve, with constraints, patterns, and things that work better than other things.

If you've ever felt like your work didn't get the credit it deserved, or you watched someone less capable than you move up because they communicated better, or you've been in a room where everyone nodded but nobody understood what you said, this book is for you.

You already know how to solve hard problems. This teaches you how to make sure other people understand the solution.

"How to Talk to Humans" is available now on Amazon. https://www.chadtdyar.com/books/how-to-talk-to-humans?utm_source=devto&utm_medium=community&utm_campaign=devto-20260827-howtotalktohuma