We will call you back within an hour and you can voice your task in more detail.
BUSINESS COMMUNICATION, UNDERSTANDING, TRUST, NETWORKING, C-LEVEL, TEAM.
Why an engineer and a product manager talk about the same thing but don’t hear each other: 4 communication roles in an IT team
figuring out where mutual understanding breaks down in IT teams
COMMUNICATIONS
Why does one talk about features while the other talks about people?
An engineer and a product manager often don’t hear each other not because someone is incompetent, but because they speak from different communication positions. Any IT team operates with four roles: the “Analyst,” the “Visionary,” the “Executor,” and the “Communicator.” Each role filters information in its own way: some hear facts, others possibilities, others concrete steps, and others the impact on people. Understanding these roles reduces the number of planning conflicts by 40–60%—these are data from my trainings in IT companies over the past three years.
Why does “deafness” arise between roles in a team?
A classic situation: the product manager says, “We need a flexible notification system that will increase retention.” The engineer hears “flexible system” and starts designing a configurator with a dozen parameters.
The product manager actually meant “add two triggers that will bring users back.”
Both are right in their own logic. The product manager thinks in terms of metrics and user behavior. The engineer thinks in terms of architecture and scalability. The problem is not the people—it’s that each automatically translates what they hear into the language of their own role.
According to McKinsey’s “The State of Organizations 2023” report, teams whose members are aware of each other’s communication differences make decisions 25% faster and make 35% fewer mistakes when passing on requirements.
4 communication roles: how to recognize them
Role 1: Analyst Perception filter: facts, data, evidence.
The Analyst hears numbers, metrics, and logical connections in a conversation. Everything else is noise. When a product manager says, “Users are complaining about notifications,” the Analyst asks: “How many complaints? For what period? What percentage of the total user base?”
Typical positions: backend developer, data engineer, QA lead.
Strength: prevents the team from making emotion‑driven decisions.
Blind spot: may block a decision by demanding data that doesn’t exist yet.
Role 2: Visionary Perception filter: opportunities, direction, strategy.
The Visionary hears potential and the future in a conversation. When an engineer says, “We have tech debt in the authorization module,” the Visionary thinks: “This is a chance to rewrite authorization and at the same time add SSO for corporate clients.”
Typical positions: product manager, CTO, founder.
Strength: sees the big picture and connects scattered tasks into a strategy.
Blind spot: can generate ideas faster than the team is able to implement them.
Role 3: Executor Perception filter: concrete steps, deadlines, owners.
The Executor hears only what can be turned into a task. When people discuss “improving onboarding,” the Executor asks: “What exactly are we doing? Who owns it? By what date?”
Typical positions: team lead, project manager, DevOps engineer.
Strength: turns conversations into results.
Blind spot: may discard an important idea just because it can’t be immediately put into Jira.
Role 4: Communicator Perception filter: relationships, emotions, impact on people.
The Communicator hears not only what is said, but how it is said. They notice that the developer has been silent for 15 minutes, that the designer tensed up after the team lead’s comment, that the client is speaking politely but is actually dissatisfied.
Typical positions: scrum master, HR business partner, account manager.
Strength: prevents conflicts before they start.
Blind spot: may delay decision‑making while trying to account for everyone’s feelings.
How roles collide in practice: a breakdown of typical conflicts
Conflict "Analyst vs Visionary"
Product manager (Visionary) at planning: "We need to completely rethink the recommendation system - this will change retention by 20%."
Developer (Analyst): "Where does the 20% figure come from? Show me the data. What's the hypothesis based on?"
The Visionary sees this as resistance. The Analyst sees the Visionary as a dreamer. Both are right: the Visionary relies on market intuition, the Analyst on verifiable facts.
Solution: The Visionary prepares 2-3 data points for the meeting confirming the direction. The Analyst phrases it not as "show me the data," but "how can we quickly test this hypothesis?"
Conflict "Executor vs Communicator"
Team lead (Executor) at retrospective: "Enough discussing feelings. Let's fix 3 specific actions and go our separate ways."
Scrum master (Communicator): "Wait, Anton hasn't spoken. And I see Marina has something to say about the last sprint."
The Executor thinks the Communicator is wasting time. The Communicator thinks the Executor is ignoring a problem that will resurface in a week. From my experience, in 70% of cases unexpressed dissatisfaction at retro turns into conflict in the next sprint.
Solution: Split the retro into 2 parts. First 15 minutes - Communicator's space: what we feel, what worries us. Second 15 minutes - Executor's space: what we do, who's responsible, deadline.
How to use knowledge of the roles in practice: 5 steps
Determine your default role. Recall your last 3 work conflicts. What did you demand from the other person—data, specifics, strategy, or attention to people? That’s your role.
Determine your counterpart’s role. Listen to which questions they ask first. “How much?” – Analyst. “Why?” – Visionary. “What should we do?” – Executor. “How does this affect people?” – Communicator.
Translate into your counterpart’s language. If you’re a Visionary talking to an Analyst, start with the numbers, not the idea. If you’re an Analyst talking to a Visionary, start with “where this will lead us,” not “what the data says.”
At key meetings, make sure all 4 roles are present. If there’s no Communicator in planning, no one will notice the team is overloaded. If there’s no Analyst, decisions will be made emotionally.
Use the “4 questions” technique. Before ending any discussion, ask in sequence: “What data supports this decision?”, “Where does this lead us?”, “Who does what and by when?”, “Does everyone agree and understand?”
Comparison table: 4 roles in IT team communication
Parameter;Analyst;Visionary;Executor;Communicator
Key question;"What data?";"Why and where to?";"What and when?";"How does this affect people?"
Perception filter;Facts and metrics;Opportunities and trends;Steps and deadlines;Emotions and relationships
Typical role;Data engineer, QA;Product manager, CTO;Team lead, PM;Scrum master, HR
Strength;Accuracy of decisions;Strategic vision;Getting results;Team health
Blind spot;Analysis paralysis;Detached from reality;Ignores context;Drags out decisions
Irritant;"I feel that…";"Show me the data";"Let’s think a bit more";"It doesn’t matter what people think"
Can one person combine several roles? Yes, and that’s normal. Everyone has a dominant role – the one they fall back into under stress. A strong leader switches between roles consciously. Developing a weak role gives a noticeable boost in communication skills in 2–3 months.
What if there is no Communicator on the team? This is common in pure engineering teams. You don’t have to assign the Communicator role to a separate person – it’s enough to embed it into processes. Add the question “What’s bothering you?” to your retro format and “How do you feel in the team?” to 1‑on‑1s. This won’t replace a strong Communicator, but it will cover 60–70% of the problems.
How do you explain this model to the team without turning the conversation into a lecture? Run a 15‑minute exercise at the next retrospective. Give descriptions of the 4 roles and ask everyone to anonymously mark: which role is their primary one and which is weak. Then show the group results – this usually triggers recognition and laughter. After that, the model starts working on its own: people begin to say “now I’ll ask as an Analyst…” or “let’s translate this into the Executor’s language.”
Does this model work in distributed teams? It does, but in distributed teams the problem is amplified. Ninety percent of nonverbal signals are lost in text communication, and the Communicator role becomes almost invisible. I recommend starting every video call in distributed teams with a 2‑minute check‑in: each participant, in one sentence, says what state they’re in right now.
How do you avoid turning this model into a label – “you’re an Analyst, so keep quiet about strategy”? The key rule: roles describe communication habits, not limitations. An Analyst can and should think about strategy, and a Visionary should look at the data. The model is not there to put people into boxes, but to explain why, in the same meeting, two smart people hear different things.
Start by defining your own role and the roles of 2–3 key colleagues. At the next planning session, try to translate your argument into the language of your counterpart’s role—and see how their reaction changes.
Subscribe to the newsletter to receive project news and announcements of new services, trainings and products, as well as useful materials on networking, dating and selling complex IT solutions.