How to Give Critical Feedback to a Coworker Without Damaging the Relationship

Your coworker keeps doing something that is hurting the team. Maybe they are consistently late on deliverables and it is blocking your work. Maybe they dominate meetings and talk over everyone. Maybe their code reviews are so surface-level that bugs keep slipping through.

You know someone needs to say something. You also know that "someone" is probably you. And the thought makes your stomach clench, because the last thing you want is to create an awkward dynamic with someone you have to work with every day.

So you say nothing. You work around the problem. You vent to a friend. And the behavior continues, getting worse while your resentment quietly grows.

Most engineers avoid giving critical feedback to peers because they have seen it go wrong. They have watched someone deliver blunt feedback that landed like an attack, or they have been on the receiving end of "constructive criticism" that felt personal. But the problem is not the feedback itself. The problem is how it gets delivered.

Why the Delivery Matters More Than the Content

Research on feedback effectiveness consistently shows that the way feedback is delivered determines whether it gets heard or triggers defensiveness. The content of the feedback can be exactly right, but if it feels like an attack on who someone is rather than what they did, the conversation goes sideways immediately.

This is the core distinction: feedback about behavior is actionable. Feedback about character is threatening.

"You are careless" is a character judgment. "The last three PRs I reviewed had the same edge case missing" is a behavior observation. The first one makes your coworker defensive. The second one gives them something specific to fix.

The SBI Framework: Situation, Behavior, Impact

The simplest feedback framework that actually works in engineering contexts is SBI. You describe three things:

1. The situation where the behavior happened (time and place)
2. The specific behavior you observed (what they did, not what you think they meant)
3. The impact that behavior had on you, the team, or the project

Here is what SBI sounds like in practice:

"In yesterday's sprint planning [situation], you cut off Alex twice when she was explaining the migration approach [behavior]. I noticed she stopped contributing after that, and we lost her input on the timeline estimates [impact]."

Compare that to: "You're really dominating meetings and it's a problem." The second version might be accurate, but it gives the other person nowhere to go except to feel attacked.

SBI works because it separates observation from judgment. You are reporting what happened, not making a diagnosis of who they are.

Five Common Situations and What to Say

When a coworker consistently misses deadlines that affect your work

"Hey, I wanted to talk about the handoffs between our work. The last two sprints, the API endpoints came in three to four days past the timeline we agreed on, and it pushed my frontend work into the final days before release. Can we talk about what is causing the delays and whether we need to adjust the timeline?"

When someone takes credit for shared work

"I noticed in the team update email, the optimization project was described as something you led. We both put significant time into that. I want to make sure we are both represented accurately. Can we update the summary together?"

When code reviews are too shallow

"I have noticed that the last few code reviews you did on my PRs were approved pretty quickly without comments. I appreciate the fast turnaround, but I am actually looking for deeper review on the payment service changes because the stakes are high. Can you give those a closer look going forward?"

When someone is negative about everything in meetings

"I have noticed that in the last few architecture discussions, the first thing you say about any proposal is what is wrong with it. Your technical objections are usually valid, but when the first response is always a critique, it makes people hesitant to share ideas. Would you be open to leading with what you think could work before flagging concerns?"

When a peer is not pulling their weight on a shared project

"I want to check in about how we are splitting the work on the data pipeline. Looking at the commit history, about 80% of the recent changes have been mine. I am not trying to keep score, but I want to make sure we are both clear on who owns what, so nothing falls through the cracks."

The Three Rules That Make It Work

Rule 1: Do it in private

Never give critical feedback in a group setting, a Slack channel, or a code review comment thread. The audience changes the dynamic completely. What feels like helpful feedback one-on-one feels like public humiliation in front of the team.

Pull the person aside. Send a DM asking for five minutes. If you are remote, hop on a quick call instead of writing a long message. Tone does not translate well in text for sensitive conversations.

Rule 2: Do it soon

The longer you wait, the less specific your feedback gets, and the more surprised the other person feels when you finally bring it up. "This happened yesterday" is much easier to discuss than "I have been noticing for months."

If the behavior is part of a pattern, address it after the second or third instance. One occurrence could be a fluke. A pattern is worth addressing.

Rule 3: Make it about the work, not the person

Every piece of feedback should be connectable to a work outcome. "Your approach is wrong" is a personal judgment. "This approach introduces a latency risk we have not accounted for" is a work observation. Keep the conversation anchored in the project, the team, or the deliverable.

What to Do If They React Badly

Sometimes, even well-delivered feedback triggers a defensive response. The other person might get angry, dismiss your concern, or turn it back on you.

If this happens, do not escalate. Say something like: "I can see this landed differently than I intended. I am not trying to attack you. Let me know if you want to revisit this later." Then give them space.

Most people need time to process feedback before they can act on it. The conversation might feel like a failure in the moment, but the seed is planted. Watch for behavior changes over the next few weeks before deciding whether to escalate.

If the behavior continues after you have addressed it directly and nothing changes, that is when it is appropriate to involve your manager. But not before you have tried the direct conversation first. Having allies who can back up your observations also helps when a pattern needs to be escalated.

Giving Feedback Is a Promotion Skill

The ability to give clear, direct, actionable feedback to peers is one of the skills that separates mid-level engineers from senior ones. At the senior level and above, every rubric includes some version of "raises the bar for the team" or "influences without authority."

Getting good at this does not mean becoming confrontational. It means becoming skilled at having honest conversations in a way that preserves the working relationship. That skill compounds over your entire career.

---

CareerClimb's AI career coach helps you practice difficult conversations before you have them for real. Describe the situation, and get word-for-word scripts tailored to your specific dynamic. Download CareerClimb