Right Feedback, Wrong Frame
A senior engineer's thorough code review left a new graduate in tears. Neither person was wrong. But both needed something the other couldn't provide without a translator in the room.
In a 1:1 that started like any other, a new engineer on my team came in visibly holding back tears. They had just received a code review from a senior engineer: thorough, pointed, and covering everything they had gotten wrong.
In their read, it was an attack. They had worked hard on the code, and the reviewer had gone through it line by line. By the end of our conversation, I had two problems: a new engineer who felt humiliated, and a senior engineer who thought they had done exactly what good code review required.
They had. The problem was that the same review landed as something personal to the person receiving it. Both reactions were consistent with where each of them was coming from.
What each person needed
I started with the new graduate. Thorough, direct code review feedback is standard in our environment because of the quality bar we hold, and I helped them see the reviewer’s comments as an investment in their improvement, not a verdict on them as a person. Learning to separate feedback on your code from feedback on you takes time, and most engineers get there.
With the senior engineer, I didn’t ask them to change how they give feedback. Their directness was a sign of engagement: in their context, going through a code review line by line is how you show you respect the work enough to take it seriously. I focused on helping them understand the gap between their intent and how it had landed.
Part of what we worked on was the craft of giving feedback to junior engineers. Pointing out what’s wrong is the easy part. The harder part is giving enough context to actually fix it and learn from it.
A comment like this runs a query per loop, which will slow things down as the table grows. Consider batching lands differently than this is inefficient. It names the specific problem, explains the stakes, and leaves a path forward. The senior engineer had the depth; the coaching was about making that depth useful to someone still building theirs.
The relationship stabilized. Future reviews became more productive. The new graduate grew more confident separating feedback on their code from feedback on them as a person.
What helped in each conversation
-
Separate intent from impact
The new engineer needed to hear that thorough code review feedback in our environment is about the quality bar, not about the person receiving it. The reviewer's comments were an investment in their growth, not a verdict on their worth as an engineer.
-
Keep the directness, sharpen the craft
Rather than asking the senior engineer to soften their style, I focused on two things: helping them understand the gap their approach had created, and coaching them on what actionable feedback looks like for junior engineers. Their directness was a sign of engagement. The work was making that engagement useful to the person on the receiving end.
-
Be the translator, not the referee
When communication norms differ, someone has to create shared understanding. The manager's job is to help both people understand each other's intent well enough to work together, without mandating a single style.
The translation layer
On multicultural teams, conflicts like this rarely come from bad intent. They come from different norms operating in the same space without anyone translating between them. My job was to build that shared understanding so the difference became workable.
That’s the translation layer a manager provides.