This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: Continual Professional Development
The problems that derail technology teams are rarely technical. They tend to arrive dressed as technical problems: a sprint that keeps slipping, a release that nobody wants to own, a team that has stopped raising concerns in stand-ups. Strip away the tooling and the terminology, and what you usually find underneath is a communication failure.
Charles Duhigg’s “Supercommunicators: How to Unlock the Secret Language of Connection” is not a management book. It draws on research from neuroscience, clinical psychology, and communication studies to argue that the best communicators operate by a set of learnable principles, and that learning them changes how conversations go in ways that compound significantly over time. Duhigg spent years studying people who seemed to connect effortlessly across difficult situations: in high-stakes negotiations, in therapy rooms, in difficult marriages, and in ordinary offices. What he found is that they were not especially charismatic in any conventional sense. They were skilled.
That distinction matters for anyone leading a technical team. Charisma is a trait: you have it or you do not. A skill is something you practise.
This post draws on the ten quotes I found most useful from Supercommunicators, and what they reveal about the kind of leadership technical teams need and, too often, do not get.
The Most Important Goal
The most important goal of any conversation is to connect.
This sounds obvious. Most tech leaders would agree with it in the abstract and then run their next stand-up as a status check.
The word “connect” is doing serious work here. Duhigg is not describing rapport-building or team bonding. Connection, in his framing, means establishing a mutual understanding of what is happening in a conversation, what each person needs from it, and how you are going to navigate it together. Most conversations never get there, because both parties assume they are already in the same conversation when they are often not.
For technical leadership, this plays out constantly. A 1:1 where the manager is addressing a performance concern and the engineer is trying to raise a technical risk is not one conversation; it is two people having parallel monologues at the same table. The most important goal of that meeting is connection, and connection requires both parties to first understand what conversation they are actually in.
Reading the Room
In many conversations, there’s a surface topic — but also a deeper, more meaningful subject that, when we bring it to light, reveals what everyone wants most from the conversation.
The surface topic is what is on the agenda. The deeper subject is why it matters to the people in the room.
A developer says the deadline is too aggressive. The surface topic is the timeline. The deeper subject might be any number of things: concern about quality, a technical risk they have not been able to articulate, a pattern of delivery pressure that has consistently led to poor outcomes. Treat it as a scheduling conversation and you will solve the scheduling problem without touching what actually needs addressing.
Duhigg argues that supercommunicators learn to listen for the gap between the surface topic and the deeper subject, and then bring that gap into the conversation. This is not therapy; it is leadership. And it is one of the most consistently underused skills I see across the teams I work with. The developers who feel heard are almost always working for leaders who have mastered this distinction; the ones who feel overlooked are almost always working for leaders who have not.
Meeting People Where They Are
When we match someone’s mindset, a permission is granted: to enter another person’s head, to see the world through their eyes, to understand what they care about and need. And we give them permission to understand — and hear — us in return.
One of Duhigg’s central frameworks is the idea that conversations fall into three broad types: practical conversations about solving problems and making decisions; emotional conversations about feelings and experiences; and social conversations about identity, values, and relationships. The same situation can be any of these three, depending on what the person in front of you needs from it.
The mistake most leaders make is defaulting to one type regardless of context. Technical leaders tend to default to the practical: here is the problem, here is the analysis, here is the proposed solution. That approach works well when the other person is also in a practical conversation. When they are in an emotional one, it lands as dismissive, even when it is not intended that way.
Matching someone’s mindset does not mean abandoning your own perspective. It means diagnosing what kind of conversation you are actually in before deciding how to respond. The permission that Duhigg describes, the opening that makes it possible for both people to genuinely hear each other, is contingent on that diagnosis. Get it wrong and the conversation runs longer, generates less clarity, and leaves people feeling unheard.
Dueling Monologues
Simply mirroring another person’s gestures, or moods, or tone of voice doesn’t forge a real connection. Giving in to someone else’s desires and preoccupations doesn’t work either. Those aren’t real conversations. They’re dueling monologues.
The dueling monologue is the default state of most technical meetings. Status updates where each person reports to the room without engaging with what anyone else has said. Architecture discussions where the senior engineer and the principal architect take turns presenting their positions without either one genuinely considering the other’s. Sprint retrospectives that produce the same action items every cycle because nothing underneath them has actually been discussed.
Duhigg is making a specific point about what real conversation requires: not compliance, not performance, not even active listening in the head-nodding sense, but genuine engagement with what the other person is bringing to the table. This is distinct from agreement. You can disagree strenuously and still be in a real conversation; you can seem to agree with everything and be in a dueling monologue.
The distinction matters because the dueling monologue is so much more comfortable. It has a structure. It ends. Nobody has to be vulnerable. Real conversations require all participants to actually encounter each other’s thinking. That is harder. It is also the only kind of conversation that produces decisions people are willing to execute.
Proving You Have Heard Them
Emotional intelligence comes from showing someone we have heard their emotions. But when we’re in a conflict or a fight, simply showing often isn’t enough. In those moments, everyone is skeptical and untrusting. Something more is needed, an extra step. To convince others we are genuinely listening during an argument, we must prove to them that we have heard them, prove we are working hard to understand, prove we want to see things from their perspective.
There is a common misconception in leadership development that listening is a passive activity: you stop talking, you pay attention, and the other person feels heard. Duhigg’s research suggests otherwise. Particularly in moments of tension, the other person is not looking for you to stop talking; they are looking for evidence that what they said actually landed.
This has direct implications for the moments tech leaders find most difficult: difficult performance conversations, post-incident reviews where something went wrong and someone is looking for a scapegoat, technical disagreements where the junior developer’s concern is being dismissed without being genuinely heard. In each of these situations, the emotional intelligence Duhigg describes is not a soft skill running parallel to the real work; it is the prerequisite for the real work. A post-incident review that reaches the wrong root cause because someone did not feel safe raising the real one is not a post-incident review. It is a document.
Proving you have heard someone requires active effort: repeating back what they said in your own words, asking questions that demonstrate you engaged with their point rather than just waiting for your turn, naming the concern underneath the concern. None of that comes naturally under pressure. It is practised.
Questions as Leadership Tools
Ask open-ended questions and listen closely. Get people talking about how they see the world and what they value most. Even if you don’t learn, right away, what others are seeking — they might not know themselves — you’ll at least inspire them to listen back.
Technical training produces engineers who are very good at closed questions: does this pass? is this correct? which option performs better? Closed questions are efficient for evaluating solutions. They are poor instruments for understanding people.
An open question that gets someone talking about how they see a problem does two things simultaneously. It gives you information you did not have, including information the other person may not have realised they had until they started talking. And it builds the kind of trust that makes the subsequent conversation, where you may have to disagree or push back, go more productively.
Having interviewed over 170 engineers, architects, and technology leaders on The Modern .NET Show, this is one of the most consistent patterns I have noticed across exceptional technical leaders: they ask more questions than they answer. They are curious about how the problem looks from where other people are standing, not just from their own vantage point. The open question is the most direct route into that curiosity, and it is one of the easiest things to practise in your next one-to-one.
The Authority Gradient Problem
Sometimes, when we try to exert control, we don’t realize we’re doing it. We think we’re simply stating our opinion or offering advice, and don’t understand that others will perceive it as attempting to strong-arm a conversation’s direction.
This is one of the most important passages in the book for anyone who has been in a technical role for a significant amount of time. The authority gradient in software teams is steep and often invisible to the people at the top of it.
A principal engineer “just thinking out loud” about an architectural approach in a design review is not having the same conversation as a junior developer. The junior developer is hearing a direction. The senior engineer may genuinely believe they are inviting debate; what they are actually doing is closing it. The same dynamic plays out between engineering managers and their teams, between technical leads and their reports, and between consultants and their clients.
This matters because the consequence of unrecognised control is not just a single poor decision. It is the accumulation of an environment where people learn not to raise alternatives, because alternatives are not genuinely welcomed even when they appear to be. Psychological safety is eroded not by deliberate intimidation but by the steady, invisible pressure of authority exercising itself without noticing it is doing so. The supercommunicator’s advantage here is self-awareness: noticing when you are steering and making a deliberate choice about whether to steer or to genuinely open the question.
Turning Arguments into Conversations
If, during moments of tension, we focus on controlling ourselves, our environment, and the conflict itself, then a fight often morphs into a conversation, where the goal is understanding, rather than winning points or wounding foes.
Technical disagreements have a particular quality. Because software teams have a high density of people who are right a lot of the time and who are used to being right a lot of the time, there is a strong pull toward treating every disagreement as a problem to be won rather than a question to be explored.
The post-incident review is the most obvious context where this matters. When a production incident has caused damage, something in the organisational immune system produces a search for someone to blame rather than something to understand. Duhigg’s framing reorients this: the goal is not to identify who was responsible for the failure but to understand how it happened, which requires a conversation oriented around understanding rather than around winning points.
The phrase “controlling the conflict itself” is worth dwelling on. It does not mean suppressing conflict or managing it toward a predetermined conclusion. It means being deliberate about what kind of conversation you are steering toward, keeping the focus on the question that actually needs answering, and redirecting when the discussion drifts into recrimination. That is a skill, and it is the skill that determines whether a post-incident review produces genuine learning or just a documented verdict.
Leading Change Without Pushing
In motivational interviewing, counsellors rarely attempt to convince or persuade. Instead, the counsellor subtly guides the client to think about and verbally express their own reasons for and against change. Motivational interviewing seeks to draw out a person’s beliefs, values, and social identities, in the hopes that, once all these complexities and complicated beliefs are on the table, unexpected opportunities for change might appear.
The standard approach to leading change in a technical team is to make the case. You gather the data, you present the argument, you explain why the new approach is better than the current one, and you expect the team to update their behaviour accordingly. This works occasionally and fails reliably, because people do not adopt new practices because they are logically demonstrated to be superior; they adopt them because they have come to believe in them.
Motivational interviewing, as Duhigg describes it, inverts the approach. Rather than building the case and presenting it, you guide the other person toward articulating their own case. You ask what concerns they have about the current approach. You ask what they would want to see if things were working better. You ask what would need to be true for them to feel confident trying something different. The reasons for change that emerge from that conversation belong to the person you are speaking with, not to you; and people will defend their own reasons far more vigorously than they will defend arguments handed to them.
Having spent almost twenty years working across more than fifty organisations, I have seen this pattern fail more times than I can count. A well-reasoned technical strategy lands without traction because the people who needed to implement it were never part of building the argument for it. The teams that actually change, and sustain that change, are the ones whose leaders understood that the job was not to convince but to create the conditions for self-convincing. Whether the change is adopting AI-assisted development practices, addressing accumulated technical debt, or realigning a team around a new set of priorities, the mechanism is the same: guide people toward their own reasons for moving.
Why Data Alone Never Wins
Stories bypass the brain’s instinct to look for reasons to be suspicious.
Technical leaders tend to make arguments from evidence. Show the metrics, present the analysis, let the data speak for itself. This is the right approach for a technical audience evaluating a technical decision. It fails consistently when applied to stakeholders who are not evaluating the technical decision so much as deciding whether they trust the person making it.
The brain’s instinct to be suspicious is not irrational; it is protective. When something is being argued at you, the natural response is to look for the flaw in the argument, the hidden agenda, the thing you are being steered away from noticing. Data activates that instinct. A well-constructed story, one in which the listener becomes absorbed in what happens next, bypasses it.
This does not mean abandoning evidence. It means understanding that evidence does not move people on its own. The case for a major architectural migration, a significant investment in security infrastructure, or a decision to pause feature development and address technical debt needs to begin with a story the stakeholder can enter: a scenario they recognise, a problem that feels real, a consequence that makes the case viscerally rather than analytically. The data then confirms what they already feel; the story is what gets them there. Few tech leaders practise it. Duhigg’s research suggests it is entirely teachable.
Becoming a Supercommunicator
Duhigg wrote this book to understand why certain people are so much better at connection than others. What he found is that they are not doing something mysterious; they are doing something consistent. Before responding, they diagnose what kind of conversation they are in. They listen for the gap between the surface topic and the deeper subject, and bring it into the open. When they ask questions, those questions are open ones. When someone speaks, they work visibly to prove they have heard it. And when they catch themselves steering a conversation, they make a deliberate choice about whether that is what they actually want to do.
None of that is advanced communication theory. It is a set of practices that improve with repetition. The gap between a leader who has these skills and one who does not is not intelligence or experience; it is attention and deliberate practice.
Technical leadership is full of conversations that matter. The one-to-one where someone tells you what they think you want to hear, because they have learned it is not safe to say anything else. The post-incident review where the real cause stays unspoken because the room is oriented around blame. The architectural debate where the most useful contribution goes unmade because junior voices have been invisibly closed down. The change initiative that fails because the people who needed to believe in it were never given a reason to.
Supercommunicators do not manage these conversations better because they are more talented. They manage them better because they learned to pay attention to what was actually happening in them, and to respond to that rather than to their own agenda. That is a skill. It is learnable. And for anyone leading a technical team, it is probably the most valuable investment you can make.
If the ideas in this post resonate with challenges you are navigating in your own team, let’s talk.