Manage cookies
Cookie Settings
Cookies necessary for the correct operation of the site are always enabled.
Other cookies are configurable.
Other cookies are configurable.
C-level, communication, negotiations
Why IT company leaders don’t listen well — and how to fix it in 3 weeks
IT company leaders don’t listen poorly because they’re not interested in people, but because their careers are built on the speed of decision-making rather than on the quality of how they perceive information.
Tech people (and their leaders) don’t know how to listen.
This is a systemic problem for technical leaders: the faster you are at solving tasks, the more your brain blocks incoming signals and switches to generating a response. Over 15 years of working with managers at conferences and trainings, I’ve seen the same picture: a CTO hears the first 20 seconds, and then is already thinking about what to say. This isn’t laziness or arrogance — it’s professional deformation. The good news is that it can be fixed in 3 weeks, provided you understand the mechanics of the problem.
Why technical leaders listen differently than they think
A 2016 Zenger/Folkman study covering 3,492 leaders found that managers rate their own listening skills on average 20% higher than their subordinates rate them. The gap between self-perception and reality was largest for technical directors among all categories.
The reason is not their personality, but their professional thinking model.
The reason is not their personality, but their professional thinking model.
How the “decision-making” brain works
An IT leader spends years training a single skill: hearing a symptom and immediately constructing a solution. In a stand-up, this is effective. In a conversation with the team, it’s destructive. The brain cannot simultaneously build a solution and absorb new information. Neurophysiologically this is called the “cognitive overload effect”: when the inner monologue is switched on, the working memory available for external signals shrinks by 40–60%.
In practice, it looks like this: a developer tells you about an architectural problem, and by their third sentence you’re already mentally rewriting the module. People sense this—and stop telling you the truth.
In practice, it looks like this: a developer tells you about an architectural problem, and by their third sentence you’re already mentally rewriting the module. People sense this—and stop telling you the truth.
Three signs you have a listening problem
Check yourself against three indicators.
If at least two match, you have a problem.
The third sign is the most accurate. If psychological safety depends on your physical absence, this is a direct consequence of how you listen.
If at least two match, you have a problem.
- You finish other people’s sentences because “it’s obvious anyway.”
- After 1-on-1 meetings, employees don’t come to you with problems on their own – only when you ask.
- In retrospectives, the team stays silent until you leave the room.
The third sign is the most accurate. If psychological safety depends on your physical absence, this is a direct consequence of how you listen.
What exactly prevents you from listening: 4 barriers for IT leaders
I distinguish four barriers that are specific to technical leaders. They differ from standard communication barriers in that they disguise themselves as competence.
Barrier 1. The “I already know this” syndrome
An experienced leader recognizes the pattern of a task from its very first words. The brain automatically tags the situation as “already known” and stops listening.
The problem: 30% of the information you think you “already know” actually contains something new. And it’s usually this “something” that changes everything.
The problem: 30% of the information you think you “already know” actually contains something new. And it’s usually this “something” that changes everything.
Barrier 2. Multitasking as the norm
In IT culture, it’s considered normal to look at a laptop and “listen” at the same time. A Stanford study (Ophir, Nass, Wagner, 2009) showed that people who work in multitasking mode filter out irrelevant information worse and switch attention more slowly than those who work sequentially. The habit of multitasking physically reduces the ability for deep listening.
Barrier 3. Status asymmetry
Когда у вас больше власти, чем у собеседника, мозг автоматически снижает уровень внимания. Это не злой умысел, а эволюционный механизм: угрозы исходят от равных и сильных, а не от подчинённых. В результате вы слушаете VP внимательнее, чем разработчика с 5‑летним опытом в предметной области.
Barrier 4. Impatience with slow thinking
Technical leaders think fast. When a counterpart thinks out loud or formulates their thoughts slowly, the leader experiences physical discomfort and either interrupts or mentally checks out. This filters out exactly those people who think deeply, but not quickly.
Diagnostics: where exactly you lose information
Before you can fix something, you need to know at which stage the loss occurs. Use this table as a quick self-diagnostic tool.
Recognize yourself?
If you recognize yourself in 3 or more of these lines, move on to the improvement program.
Correction program: 3 weeks, one skill at a time
I deliberately introduce just one change per week. Trying to change everything at once doesn’t work — under pressure, the brain falls back to its automatic patterns. One skill, built into your routine, changes more than five skills that you only remember during the training.
Week 1. Physical protocol “closed laptop”
The rule is simple: in any 1‑on‑1 meeting or team discussion, the laptop is closed and the phone is placed face down. No exceptions for 7 days.
It sounds trivial. But in my experience, this is exactly the change that causes the most resistance among technical leaders — and produces the fastest visible result. The team notices the difference by the second or third meeting. People start talking more, because they see that they are being heard.
Weekly metric: count how many times during the week you learned something you didn’t know before the meeting. Write it down. This is your baseline number.
It sounds trivial. But in my experience, this is exactly the change that causes the most resistance among technical leaders — and produces the fastest visible result. The team notices the difference by the second or third meeting. People start talking more, because they see that they are being heard.
Weekly metric: count how many times during the week you learned something you didn’t know before the meeting. Write it down. This is your baseline number.
Week 2. The “Last 3 Words” technique
When the other person finishes a thought, repeat out loud their last 2–3 words with a questioning intonation. This isn’t manipulation or NLP tricks – it’s a physiological technique that forces you to listen until the end and gives the person a signal to continue.
Example. The developer says: “…and I think we need to reconsider the microservices architecture.” You: “Reconsider the architecture?” They continue. In 80% of cases, the essence of the problem they didn’t dare to state directly will be in the next two sentences.
Weekly metric: use this technique in at least 5 conversations. After each one, write down 1 sentence about what new you learned.
Example. The developer says: “…and I think we need to reconsider the microservices architecture.” You: “Reconsider the architecture?” They continue. In 80% of cases, the essence of the problem they didn’t dare to state directly will be in the next two sentences.
Weekly metric: use this technique in at least 5 conversations. After each one, write down 1 sentence about what new you learned.
Week 3. The 2‑Minute Silence Rule
Before you respond to any question or problem from your team, pause for at least 5 seconds. Ask a clarifying question: “Tell me more” or “What have you already tried?”
The goal is not to drag out the conversation, but to make sure you have understood the task correctly before you start solving it. According to consulting firm McKinsey, 67% of wrong decisions in product teams happen because the task was misunderstood, not because the solution was wrong.
Weekly metric: for 7 days, track how many times a clarifying question changed your initial understanding of the situation.
The goal is not to drag out the conversation, but to make sure you have understood the task correctly before you start solving it. According to consulting firm McKinsey, 67% of wrong decisions in product teams happen because the task was misunderstood, not because the solution was wrong.
Weekly metric: for 7 days, track how many times a clarifying question changed your initial understanding of the situation.
What happens after three weeks
In 21 days, you won’t become a perfect listener. But you will see several concrete changes that I consistently observe in leaders who go through this practice.
First, the flow of information from bottom to top will increase. People start coming to you with problems on their own, earlier than when those problems become critical. This directly saves you money on “firefighting.”
Second, the quality of your decisions will improve, because they’ll be based on the full picture, not on the first 30 seconds of a conversation.
Third, and most unexpectedly, you’ll free up energy. Pretending to listen while simultaneously solving a problem requires more cognitive resources than actually being present in the conversation.
Listening is not a “soft skill.” It’s decision‑making infrastructure. And it requires the same systematic approach as any technical infrastructure: diagnostics, architecture, and regular maintenance.
First, the flow of information from bottom to top will increase. People start coming to you with problems on their own, earlier than when those problems become critical. This directly saves you money on “firefighting.”
Second, the quality of your decisions will improve, because they’ll be based on the full picture, not on the first 30 seconds of a conversation.
Third, and most unexpectedly, you’ll free up energy. Pretending to listen while simultaneously solving a problem requires more cognitive resources than actually being present in the conversation.
Listening is not a “soft skill.” It’s decision‑making infrastructure. And it requires the same systematic approach as any technical infrastructure: diagnostics, architecture, and regular maintenance.
FAQ
How can I tell if I really listen poorly and not just process information quickly?
Ask three different people on your team to anonymously answer one question: “Do you feel heard in meetings with me?” If at least two say “not always,” there is a problem. Fast information processing does not compensate for the absence of a clear signal of presence for the other person.
Do I need to listen to everyone equally attentively, or can I prioritize?
Prioritizing by meeting type is fine. A strategy session requires a different level of attention than a quick sync. But within each meeting, be fully present—or don’t start it. A meeting where you “half‑listen” costs more than postponing it by 30 minutes.
How do I listen attentively when I have 8 meetings a day?
This is not a listening issue, it’s a calendar issue. Eight meetings a day are a symptom of a systemic problem with delegation or process structure. Cut the number of meetings down to those where your presence truly changes the outcome. In the remaining ones, listen fully.
What should I do if the other person talks for a long time and can’t get to the point?
That’s not a reason to switch off, it’s a reason to intervene constructively. After 2–3 minutes, say: “Let me stop you for a second—what decision do you need from me as a result of this conversation?” This brings back focus and saves both of you time.
Can I teach the team to listen to each other better if I’m only just starting to practice this myself?
Yes—and it’s actually the most effective strategy. Change begins with visible behavior from the leader. When the team sees you closing your laptop and asking clarifying questions, they start doing the same in their own interactions. This is called behavior modeling, and in corporate culture it works faster than any training.
Ask three different people on your team to anonymously answer one question: “Do you feel heard in meetings with me?” If at least two say “not always,” there is a problem. Fast information processing does not compensate for the absence of a clear signal of presence for the other person.
Do I need to listen to everyone equally attentively, or can I prioritize?
Prioritizing by meeting type is fine. A strategy session requires a different level of attention than a quick sync. But within each meeting, be fully present—or don’t start it. A meeting where you “half‑listen” costs more than postponing it by 30 minutes.
How do I listen attentively when I have 8 meetings a day?
This is not a listening issue, it’s a calendar issue. Eight meetings a day are a symptom of a systemic problem with delegation or process structure. Cut the number of meetings down to those where your presence truly changes the outcome. In the remaining ones, listen fully.
What should I do if the other person talks for a long time and can’t get to the point?
That’s not a reason to switch off, it’s a reason to intervene constructively. After 2–3 minutes, say: “Let me stop you for a second—what decision do you need from me as a result of this conversation?” This brings back focus and saves both of you time.
Can I teach the team to listen to each other better if I’m only just starting to practice this myself?
Yes—and it’s actually the most effective strategy. Change begins with visible behavior from the leader. When the team sees you closing your laptop and asking clarifying questions, they start doing the same in their own interactions. This is called behavior modeling, and in corporate culture it works faster than any training.
Leonid Bugaev
is an expert in business communications, a corporate trainer, speaker, and conference moderator. He is the author of the books “Mobile Marketing”, “Mobile Networking” and "People Like Me: 99 Rules for Building Connections That Actually Matter."
Follow Leonid on Telegram, Facebook, Instagram, and YouTube so you don’t miss new publications. Also take a look at his business training programs on networking, B2B sales and trendwatching, as well as his books and interviews.
Follow Leonid on Telegram, Facebook, Instagram, and YouTube so you don’t miss new publications. Also take a look at his business training programs on networking, B2B sales and trendwatching, as well as his books and interviews.
About, Clients & Testimonials
Business Services
Events