Giving feedback about communication problems is one of the most delicate tasks an engineering leader faces. Unlike technical skills, communication feels personal. Engineers often interpret feedback about how they speak or write as a judgment on their intelligence or character. Done poorly, the feedback can damage trust or shut down collaboration. Done well, it can unlock a engineer’s ability to contribute more effectively to the team and the organization. This article lays out a practical approach for giving that feedback with clarity, empathy, and lasting impact.

Understanding Why Communication Problems Happen

Communication breakdowns in engineering teams rarely stem from a single cause. Before you give feedback, take time to understand the underlying reasons. Many engineers come from backgrounds where dense technical writing and detailed verbal explanations were valued. When they move into cross functional teams or leadership roles, the same style can create confusion. Others may be working in a second language, processing in real time, or dealing with cognitive load from complex systems. Still others may have anxiety about public speaking or writing that leads to avoidance or oversimplification. Recognizing these root causes helps you tailor your feedback and adjust your expectations.

A second layer to consider is the team culture. If the team tolerates vague requirements, asynchronous silence, or email ping pong, it reinforces poor habits. The engineer may not realize that their communication style is causing friction because nobody has clearly defined what effective communication looks like in that context. By identifying whether the problem is individual, systemic, or a mix of both, you can decide whether feedback is enough or whether you need to also change team norms.

Common Communication Issues in Engineering Teams

Certain patterns of communication problems appear regularly. One is explaining too much or too little. Some engineers dive into implementation details before stating the problem or the desired outcome, leaving listeners overwhelmed. Others give a one line answer to a complex question and assume everyone understands the context. Another pattern is poor written communication in pull requests, design documents, or tickets: missing context, unclear reasoning, or overly long explanations that bury the key point. Meeting communication can also be problematic, such as interrupting, going off topic, or staying silent when contribution is needed. A related but distinct issue is failing to adapt the communication style to the audience. An engineer might explain a system to a product manager using the same language they would use with a fellow developer, which creates confusion or disengagement.

Each of these patterns requires a slightly different feedback approach. A blanket statement like ‘you need to communicate better’ is useless. Instead, identify the specific situation and the specific behavior you want to change. For example, instead of saying ‘your writing in design docs is hard to follow’, you could say ‘in the last two design documents, you started with the algorithm details before explaining the problem the team is trying to solve. That made it hard for the reviewers to understand why your approach was chosen.’.

Preparing for the Feedback Conversation

Preparation separates effective feedback from vague criticism. Start by gathering concrete examples. Pick two or three recent instances where the communication issue was visible. Write down what happened, who was involved, and what the impact was. For instance, ‘during the sprint planning meeting on Tuesday, you described the technical approach for the authentication module without first explaining the user story this approach supports. Three team members asked clarifying questions that extended the meeting by fifteen minutes.’ This level of detail makes the feedback undeniable and actionable.

Next, decide on the goal of the conversation. Do you want the engineer to change a specific behavior, develop a new skill, or just become aware of the issue? Most feedback for communication problems falls into the awareness and skill development categories. If the engineer is already aware but struggling, the conversation should focus on support and practice rather than correction. If they are unaware, your first job is to illuminate the gap.

Choose a private setting with enough time. A fifteen minute hallway chat is rarely enough. Schedule a thirty minute one on one specifically for this topic, and let the engineer know the general subject in advance so they are not blindsided. Write something like ‘I would like to talk about communication during team meetings and how we can make it more effective for everyone.’ This respects their psychological safety and gives them a chance to prepare.

Framing Feedback Constructively

The framing of the feedback determines how it is received. Start with a positive intent statement. For example, ‘I want to talk about something that I think will help you have more impact in meetings, because your technical insights are valuable and I want them to be heard more clearly.’ This sets the tone that you are on their side and that change is about increasing their effectiveness, not punishing a flaw.

Use the situation behavior impact model. Describe the specific situation, the observable behavior, and the impact on the team or project. Avoid judgments like ‘you were confusing’ or ‘you rambled’. Instead, stick to facts. For example, ‘during yesterday’s architecture review, when you presented the caching strategy, you spent the first ten minutes on low level implementation details. The product manager and the data engineer could not follow the trade offs, so we had to reschedule the decision for next week.’ This gives the engineer a clear understanding of what happened and why it matters.

After describing the impact, pause and ask for their perspective. Say something like ‘does that match what you experienced?’ or ‘how do you see it?’ This invites dialogue rather than monologue. The engineer might reveal that they felt rushed, or that they assumed the audience had more context than they actually had. This information helps you find the right solution together.

Coaching Approaches for Different Scenarios

The way you coach depends on the root cause. If the problem is about overexplaining technical details, suggest a simple framework: start every explanation with what problem you are solving, then why the approach matters, and only then go into how. You can role play a short example during the conversation. If the issue is undercommunicating, encourage the engineer to develop a habit of adding context. For written communication, suggest using templates or checklists like the standard design doc format that includes sections for context, goals, and non goals. For verbal communication, recommend that they prepare a one sentence summary of their message before speaking in a meeting.

Some engineers benefit from explicit audience mapping. Ask them to think about who will read or hear their communication and what each person needs to know. A simple exercise is to write down the top three questions each audience member would have after reading a draft. If the draft does not answer those questions, it needs revision. This is especially useful for engineers who write excellent code but produce documentation that confuses people outside their immediate team.

For engineers who avoid speaking in meetings, the approach is different. Work with them to identify low risk opportunities to contribute, such as providing an update on their own work or asking a clarifying question. Celebrate those small steps. Over time, increase the stakes. You can also pair them with a more communicative engineer for peer mentoring or have them present in a team brown bag session where the audience is friendly and the topic is familiar.

Following Up and Measuring Progress

Feedback without follow up rarely leads to change. After the conversation, agree on one specific action the engineer will take and one specific thing you will do to support them. For example, the engineer might agree to write the next design doc using the context first approach, and you agree to review a draft before it goes to the full team. Set a timeline. Check in after a week or two, not after six months.

Look for signs of improvement in the situations you discussed. Did the engineer start meetings with context? Did they write clearer pull request descriptions? Acknowledge progress openly. Say something like ‘I noticed in the last two standups you started with the what and why before going into details. That made it much easier for the team to follow your updates.’ Positive reinforcement is as important as corrective feedback.

If the issue does not improve after multiple conversations and coaching attempts, consider whether there is a deeper mismatch. Sometimes an engineer’s communication style is so misaligned with the role that no amount of coaching can bridge the gap. In that case, the feedback conversation might need to shift to role expectations and career growth, possibly leading to a different position where their strengths are more valuable and the communication demands are lower.

When to Escalate or Involve Others

Not all communication problems can be solved by one on one coaching. If the issue affects a significant part of the team’s productivity, or if the engineer is in a leadership position where communication is a core requirement, you may need to involve a communication coach, a speech therapist, or a professional development program. Some companies offer internal training on technical writing or presentation skills. If those resources exist, use them.

You should also involve your own manager or HR if the communication problem is causing conflict, reducing psychological safety, or leading to repeated misunderstandings that affect project outcomes. The goal is not to punish the engineer but to get additional support. Frame the escalation as a collaboration to find better tools or interventions, not as a complaint.

Finally, remember that communication is a two way street. As the leader, you can also improve how you listen and how you set expectations. By modeling clear, empathetic communication yourself, you create a standard that makes it easier for engineers to understand what good looks like. Give feedback on communication with the same rigor and care you would give feedback on code quality. The results will be a more cohesive team and engineers who can take their skills further.