Beyond technical skills: Communication

I once spent two weeks building a case for migrating a core service to a new architecture. The data was solid. The cost savings were real. The risk analysis was thorough. I walked into the meeting confident, presented my slides, and watched the room slowly disengage. By the end, the decision was to "revisit next quarter," which in corporate speak meant never.

A colleague pulled me aside afterward and said something I've never forgotten: "Your proposal was right. But you started with the solution instead of the problem. Half the room didn't even know there was a problem."

That moment taught me something no coding challenge or system design interview ever tested: it doesn't matter how right you are if you can't bring people along with you. Communication isn't a nice-to-have for engineers. It's the multiplier on every other skill you've built. And like most multipliers, when it's at zero, it doesn't matter how large the other numbers are.

In the first post in this series, I covered the books I wish someone had handed me on day one. This one is about the skill I had to learn the hardest way: talking to other humans about technical work.

Framing the conversation

After that meeting, I started paying attention to how the people who consistently got buy-in actually structured their proposals. And I noticed something. The best communicators I worked with rarely started with what they wanted. They started by shaping how the audience thought about the problem before the solution ever came up.

Robert Cialdini's Influence gave me a framework for what I'd been observing. His six principles of persuasion (reciprocity, commitment, social proof, liking, authority, scarcity) aren't manipulation tactics. They're descriptions of how humans actually make decisions. Once I understood that people look for social proof before committing to a direction, I stopped leading with "here's what I think" and started leading with "here's what we've seen work in similar situations." Same idea, completely different reception. What surprised me is how broadly these principles apply. The same dynamics show up when you're trying to build consensus across teams without formal authority, or when you're designing a user flow that needs to guide people toward a better decision.

His follow-up, Pre-Suasion, goes deeper into the setup. The central argument is that what happens before you make your case matters as much as the case itself. The "privileged moment" concept changed how I run architecture reviews. I started sending a one-page problem statement the day before, framing the challenge in terms the audience cared about. By the time we sat down, the conversation was already pointed in the right direction. No slides needed to convince people there was a problem; they'd already been thinking about it.

Together, these two books explain why technically correct proposals fail and technically weaker ones sometimes win. The difference is rarely the content. It's the framing.

Presenting data clearly

Engineers love data. We measure everything. But there's a gap between having the data and making it land with an audience that doesn't share your context.

I learned this the hard way when I built a dashboard showing the performance impact of a caching layer we'd implemented. The numbers were impressive: p99 latency down 40%, cache hit ratio at 92%, cost per request cut in half. I was proud of it. My engineering peers loved it. But when I showed the same dashboard to product leadership, I got blank stares. Too many metrics, no narrative, no answer to "so what does this mean for us?"

Cole Nussbaumer Knaflic's Storytelling with Data reframed how I think about presenting numbers. The core lesson is deceptively simple: every chart should answer one question, and the audience should be able to identify that question within seconds. She provides concrete techniques for choosing the right visualization, removing clutter, and building a narrative arc through data. The book is practical in a way that most data visualization guides aren't; it's less about chart types and more about understanding your audience's needs and meeting them where they are.

After reading it, I rebuilt that dashboard. Same data, but structured around three questions product leadership actually cared about. It took less time to build and got twice the engagement. The same skill applies in reverse, too: when you're building dashboards or data features for end-users, understanding what story the data needs to tell makes you a better engineer, not just a better presenter.

Understanding what others actually hear

Even with good framing and clean data, communication breaks down in ways that catch you off guard. You say something clear (to you) and the other person hears something completely different. This happens in code reviews, in 1-on-1s, in cross-team meetings, in user interviews. And it's not because anyone is being difficult. It's because understanding strangers, and even understanding colleagues you see every day, is genuinely harder than we think.

Malcolm Gladwell's Talking to Strangers explores this through a lens he calls the "transparency illusion," the assumption that we can accurately read other people's intentions and emotions from their behavior. We can't, not nearly as well as we believe. Gladwell makes the case through stories that range from espionage to criminal justice, but the engineering application is immediate. How often have you assumed a quiet person in a meeting was disengaged, when they were actually processing deeply? How many times has written feedback in a pull request come across harsher than intended? The same blind spot shows up in hiring. We run a 45-minute interview and walk out convinced we know whether someone can do the job. Gladwell's research suggests we're far less accurate at that judgment than we think.

Charles Duhigg's Supercommunicators picks up the practical side. His key insight is that conversations operate in three modes: practical (solving a problem), emotional (processing a feeling), and social (navigating identity and belonging). Miscommunication happens most often when people are in different modes. You're in practical mode explaining the technical tradeoffs; they're in emotional mode because the deadline stress is real. Neither of you is wrong, but you're not in the same conversation.

Duhigg's framework for mode-switching has been one of the most useful mental models I've adopted. Before responding in a tense situation, I ask myself: what mode are they in, and what mode am I in? That pause alone has saved me from dozens of conversations that would have gone sideways. It also changed how I translate technical concepts. When I'm explaining a system design to a product manager, I'm not just simplifying; I'm switching to their mode, framing the architecture in terms of user impact and business risk rather than implementation details.

The fundamentals of connection

Dale Carnegie's How to Win Friends and Influence People was published in 1936, and every time I mention it someone raises an eyebrow. The title sounds like a manipulation manual. It's not. It's a book about genuine interest in other people, and it's still relevant because the fundamentals of human connection haven't changed in the decades since.

The principles are almost embarrassingly simple: remember names, listen more than you talk, let people feel ownership of ideas, admit when you're wrong. I resisted this book for years because it felt too basic. When I finally read it, I realized that "basic" and "easy" are not the same thing. I knew I should listen more in meetings. I didn't actually do it consistently until Carnegie's framing made me see how much I was missing.

What makes this book relevant for engineers specifically is that our training actively works against some of these habits. We're trained to find flaws, to debug, to point out what's wrong. Those skills make you a great code reviewer. They make you a terrible conversationalist. Carnegie's book is a useful counterweight: a reminder that being right about a technical detail matters less than making the other person feel heard.

Communication as a career multiplier

The connecting thread across these six books isn't rhetoric or persuasion tricks. It's awareness. Awareness of how you frame problems before presenting solutions. Awareness of the gap between what you say and what others hear. Awareness that data needs a story, not just accuracy. Awareness that the fundamentals of connecting with people are simple to understand and hard to practice consistently.

I've watched brilliant engineers plateau because they couldn't communicate their ideas beyond their immediate team. And I've watched good (not great) engineers have outsized impact because they could bring people along with them. The technical skills get you in the door. Communication determines how far you go once you're inside.

If there's one takeaway from this list, it's that communication isn't a personality trait. It's a skill. And like any skill, it improves with deliberate practice and the right mental models. These books gave me mine.

The list