Have questions ?
We will call you back within an hour and you can voice your task in more detail.
Manage cookies
Cookie Settings
Cookies necessary for the correct operation of the site are always enabled.
Other cookies are configurable.
Other cookies are configurable.
BUSINESS COMMUNICATION, UNDERSTANDING, TRUST, NETWORKING, C-LEVEL, TEAM.
“I thought you got it” is the most expensive phrase in an IT project
Three techniques that will help you make sure the team has understood the task correctly—without it feeling like an exam and without causing irritation.
C-LEVEL COMMUNICATIONS
Why “I thought you got it” kills deadlines and motivation in an IT team
The phrase “I thought you got it” costs IT teams weeks of overtime, missed releases, and broken relationships inside the team. Very few people know how to check a counterpart’s understanding without causing irritation—most managers and team leads either don’t do it at all, or do it in a way that makes the other person feel like an idiot.
There are 3 specific techniques that work in any format—at standups, in Slack, and in meetings with a client: “paraphrase,” “control question,” and “summary from the interlocutor.” They are applicable in any IT team where tasks are communicated orally or in writing, and where status differences create a barrier to asking clarifying questions.
There are 3 specific techniques that work in any format—at standups, in Slack, and in meetings with a client: “paraphrase,” “control question,” and “summary from the interlocutor.” They are applicable in any IT team where tasks are communicated orally or in writing, and where status differences create a barrier to asking clarifying questions.
Why misunderstandings in IT cost more than you think
According to a 2023 study by the Project Management Institute (PMI), poor communication is the main reason for the failure of 31% of IT projects. The average cost of rework due to misunderstood requirements in projects with teams of 20+ people ranges from 15 to 40% of the sprint budget.
I’ve been running communication trainings in IT companies for over 10 years and I keep seeing the same picture: a task is given verbally, everyone nods, no one asks a single clarifying question.
Two weeks later it turns out that the backend developer understood “flexible authorization” one way, and the product manager—completely another.
Game over.
I’ve been running communication trainings in IT companies for over 10 years and I keep seeing the same picture: a task is given verbally, everyone nods, no one asks a single clarifying question.
Two weeks later it turns out that the backend developer understood “flexible authorization” one way, and the product manager—completely another.
Game over.
Why people don’t ask for clarification
There are three reasons, and they’re not about inattention.
The first is the fear of looking incompetent. In the culture of most large IT companies, asking again means admitting you didn’t understand. It’s seen as a weakness, especially when a team lead or CTO is nearby.
The second is the illusion of understanding. A person hears familiar words—“integration,” “microservice,” “flow”—and the brain automatically fills in the picture from past experience. The picture turns out to be wrong, but subjectively everything feels clear.
The third is the pace. In a mode of constant meetings, when the next call is in 15 minutes, no one wants to slow the conversation down with clarifications.
We running? We ruuun!
The first is the fear of looking incompetent. In the culture of most large IT companies, asking again means admitting you didn’t understand. It’s seen as a weakness, especially when a team lead or CTO is nearby.
The second is the illusion of understanding. A person hears familiar words—“integration,” “microservice,” “flow”—and the brain automatically fills in the picture from past experience. The picture turns out to be wrong, but subjectively everything feels clear.
The third is the pace. In a mode of constant meetings, when the next call is in 15 minutes, no one wants to slow the conversation down with clarifications.
We running? We ruuun!
Two cases I have personally observed
Case 1: “A simple tweak” over three sprints
At sprint planning in a large fintech startup (60‑person team, Moscow), the product manager told a developer: “We need to refine the notification module—make it more flexible.” The developer nodded. Neither side asked any follow‑up questions.
Three weeks later the product saw the result and said: “This is not what I meant.”
The developer had built a notification configurator with 12 parameters. The product only wanted to add two new triggers.
The cost of the mistake was three weeks of one developer’s time. The reason: the word “flexible” meant something different to each participant in the conversation.
Case 2: Onboarding a new team lead
In the development team of an e‑commerce project, a new team lead, after his first meeting with the CTO, said: “Everything’s clear, I understand the goals for the quarter.”
I asked him to restate in his own words the three main priorities.
He got only one of the three right.
He either confused the other two with last quarter’s goals or added things the CTO had never said. At the same time, subjectively, the team lead was sure he had understood everything.
This is a classic case of the “illusion of understanding”: a person hears familiar words and doesn’t notice that they’ve mentally filled in the meaning from their past experience.
At sprint planning in a large fintech startup (60‑person team, Moscow), the product manager told a developer: “We need to refine the notification module—make it more flexible.” The developer nodded. Neither side asked any follow‑up questions.
Three weeks later the product saw the result and said: “This is not what I meant.”
The developer had built a notification configurator with 12 parameters. The product only wanted to add two new triggers.
The cost of the mistake was three weeks of one developer’s time. The reason: the word “flexible” meant something different to each participant in the conversation.
Case 2: Onboarding a new team lead
In the development team of an e‑commerce project, a new team lead, after his first meeting with the CTO, said: “Everything’s clear, I understand the goals for the quarter.”
I asked him to restate in his own words the three main priorities.
He got only one of the three right.
He either confused the other two with last quarter’s goals or added things the CTO had never said. At the same time, subjectively, the team lead was sure he had understood everything.
This is a classic case of the “illusion of understanding”: a person hears familiar words and doesn’t notice that they’ve mentally filled in the meaning from their past experience.
3 techniques for checking understanding that don’t annoy your counterpart
Irritation arises when a comprehension check sounds like an exam or an expression of distrust. None of the three techniques below is directed “at the other person” — they are all phrased so that the speaker takes responsibility themselves.
Technique 1: First-person paraphrasing
Instead of “Do you understand?” say, “Let me check whether I explained it clearly.” It’s a simple but powerful shift: you’re not testing your counterpart, you’re checking yourself as a communicator.
Formula: “To make sure I’ve conveyed the main point, could you put it in your own words and tell me how you understand the task?”
Formula: “To make sure I’ve conveyed the main point, could you put it in your own words and tell me how you understand the task?”
Technique 2: Control question about the next step
After assigning a task, ask just one question: “What’s the first thing you’ll do?” or “Where will you start?”
The answer immediately shows whether the person has really understood the task or just nodded along.
I use this technique in trainings with managers from large companies.
In roughly 40% of cases, the first step they name does not match what the task-giver actually expected.
The answer immediately shows whether the person has really understood the task or just nodded along.
I use this technique in trainings with managers from large companies.
In roughly 40% of cases, the first step they name does not match what the task-giver actually expected.
Technique 3: Summary from the counterpart at the end of the meeting
At the end of any meeting where decisions were made, ask one of the participants to say out loud: who is doing what, by what deadline, and what result is expected?
Note: this is NOT the meeting minutes, but a live check of understanding right now, while it’s still possible to correct any discrepancies.
Note: this is NOT the meeting minutes, but a live check of understanding right now, while it’s still possible to correct any discrepancies.
What does a comprehension check look like in different formats?
What prevents managers from using these techniques?
Three barriers I observe in trainings with IT team leaders.
The first barrier is “I don’t want to waste time.” Checking understanding takes 2–3 minutes. Rework caused by a misunderstood task takes from 3 days to 3 weeks.
The second barrier is “They’re adults, they’ll ask again themselves.” They won’t. Especially if it’s a junior in front of a team lead, or a team lead in front of a CTO. Hierarchy kills clarifying questions faster than any other factor.
The third barrier is the habit of “synchronization.” The phrase “we’re in sync” has become a corporate meme that hides exactly what this article is about: the appearance of understanding instead of the real thing.
The first barrier is “I don’t want to waste time.” Checking understanding takes 2–3 minutes. Rework caused by a misunderstood task takes from 3 days to 3 weeks.
The second barrier is “They’re adults, they’ll ask again themselves.” They won’t. Especially if it’s a junior in front of a team lead, or a team lead in front of a CTO. Hierarchy kills clarifying questions faster than any other factor.
The third barrier is the habit of “synchronization.” The phrase “we’re in sync” has become a corporate meme that hides exactly what this article is about: the appearance of understanding instead of the real thing.
FAQ
How can you check understanding without offending an experienced developer?
Use a first-person paraphrasing technique: “I want to make sure I explained it clearly — can you tell me in your own words how you understand the task?” This wording puts the responsibility on you as the task-giver instead of putting the developer in the role of a student.
What if the person still restates the task incorrectly?
Don’t correct immediately — first clarify where their understanding comes from. Say: “Interesting, tell me more — why did you decide it should be done this way?” After that, adjust their understanding.
Do you need to check understanding in every conversation?
No. Use checks when the task is multi-step, the result is ambiguous, or participants have different levels of context. For simple operational tasks (“update dependencies,” “post in the channel”), it’s enough to log them in the tracker.
How do you apply these techniques in async communication — in Slack or Jira?
In Slack: end the task description with a question like “Do I understand correctly that you’ll take this into work today?” and wait for explicit confirmation, not just an emoji reaction.
In Jira: add an “Expected result” section to the task description with a concrete definition of done.
Why don’t teams talk about understanding problems in retrospectives?
Because retros usually focus on processes, not communication. People say “we didn’t make it,” “there were blockers,” but don’t explicitly say “we didn’t understand the task.” Add one question to the retro format: “Was there a moment when you thought you’d understood something, but it turned out you hadn’t?” — this opens the right conversation.
Use a first-person paraphrasing technique: “I want to make sure I explained it clearly — can you tell me in your own words how you understand the task?” This wording puts the responsibility on you as the task-giver instead of putting the developer in the role of a student.
What if the person still restates the task incorrectly?
Don’t correct immediately — first clarify where their understanding comes from. Say: “Interesting, tell me more — why did you decide it should be done this way?” After that, adjust their understanding.
Do you need to check understanding in every conversation?
No. Use checks when the task is multi-step, the result is ambiguous, or participants have different levels of context. For simple operational tasks (“update dependencies,” “post in the channel”), it’s enough to log them in the tracker.
How do you apply these techniques in async communication — in Slack or Jira?
In Slack: end the task description with a question like “Do I understand correctly that you’ll take this into work today?” and wait for explicit confirmation, not just an emoji reaction.
In Jira: add an “Expected result” section to the task description with a concrete definition of done.
Why don’t teams talk about understanding problems in retrospectives?
Because retros usually focus on processes, not communication. People say “we didn’t make it,” “there were blockers,” but don’t explicitly say “we didn’t understand the task.” Add one question to the retro format: “Was there a moment when you thought you’d understood something, but it turned out you hadn’t?” — this opens the right conversation.
Let’s learn to understand each other. Carefully :-0
Checking understanding is not about distrusting the team; it’s professional communication hygiene. Spending 2–3 minutes clarifying a task at the start saves you from 2–3 weeks of rework at the end. Start with a single technique—first-person paraphrasing—and use it in your next five meetings.
instead of “spray the paint on the camera,” it’s sometimes easier to say: “…no, not on me, but in front of the camera!”
but after that — what can you even say? :)
but after that — what can you even say? :)
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