How to Write a Peer Review for Someone You Have Concerns About

You have been asked to write a peer review for someone whose work has been a problem. Maybe they miss deadlines consistently. Maybe their code quality has been slipping. Maybe they are difficult to collaborate with in meetings. You know something needs to be said, but you do not know how to say it without sounding like you are throwing them under the bus.

So you face the same dilemma most engineers face: write something vaguely positive and hope someone else raises the concern, or be honest and risk damaging the relationship.

Neither option is great. But there is a middle path that is honest, specific, and constructive without being cruel. That is what this guide is for.

Why honest peer reviews matter

Peer reviews are not just a checkbox. They are one of the few mechanisms that surface real performance data in calibration. Managers use them as a signal. If every peer review for someone is glowing and their output is mediocre, the manager loses a valuable data point.

A survey by Zenger and Folkman published in HBR found that 92% of people believe negative feedback, delivered well, improves performance. Your coworker may not know they have a problem. Your peer review might be the first time someone tells them clearly.

Avoiding honest feedback is not kindness. It is a choice to let the problem continue. The broader peer feedback guide covers the full spectrum of peer reviews, but this article focuses specifically on the hard cases.

The mindset shift: you are helping, not hurting

Before you write a single word, reframe the exercise in your head. You are not writing a complaint. You are providing information that could help this person improve and succeed.

Think about it from the other direction: if your work had been slipping and nobody told you, would you want to find out during a PIP? Or would you rather a peer flagged it early enough for you to course-correct?

Honest peer feedback, delivered with care, is one of the most valuable things you can give a coworker. It is the kind of feedback that is hard to get from a manager (who might be too diplomatic) or from yourself (who might not see the pattern).

How to write it: the four-step framework

Step 1: Lead with context and relationship

Start by establishing the working relationship. This grounds the feedback and signals that you are speaking from direct experience, not rumor.

"I worked closely with [name] on [project] during [timeframe]. We interacted [daily/weekly/in code reviews/in design discussions]."

This matters because peer feedback that comes from someone with direct exposure carries more weight than feedback from a distant colleague. And it shows the reviewer that you are being fair, not speculative.

Step 2: Acknowledge strengths first (but do not pad)

Even when you have concerns, there are almost certainly things this person does well. Name one or two. Be specific. This is not a compliment sandwich. It is honesty.

"Their knowledge of the payments system is deep, and when we hit a production incident in January, they were the person who diagnosed the root cause."

This matters because starting with genuine strengths makes the constructive feedback that follows feel balanced rather than like an attack. But do not force it. If you cannot think of a genuine strength, do not make one up.

Step 3: Name the concern with specifics

This is the hard part. Use the SBI framework (Situation, Behavior, Impact) to keep it concrete.

Vague (unhelpful): "Their code quality needs improvement."

Specific (useful): "In the last three PRs I reviewed for [project], each one had significant issues: missing tests, race conditions, and an approach that did not match the agreed-upon design doc. I flagged these in review, but the patterns repeated across all three."

Vague (unhelpful): "They are hard to work with."

Specific (useful): "During sprint planning for the last two sprints, they committed to deliverables they did not complete, which shifted the remaining work to other team members, including me. On the migration project, I ended up covering three of their action items in the final week."

Step 4: Frame it as a growth opportunity

End with a forward-looking statement. Not "they should stop doing X" but "I think they would benefit from Y."

"I think [name] would benefit from tighter scoping before starting implementation. A couple of projects expanded significantly from the original plan, which created pressure on the rest of the team. With more upfront alignment on scope, their strong technical skills would translate into more consistent delivery."

This framing says: "I believe in their potential. Here is what I think would unlock it." It is honest without being harsh.

Phrases you can use for common concerns

For missed deadlines or inconsistent delivery:

• "There were several instances this cycle where committed deliverables were delayed or required significant rework, which affected the team's timeline."
• "I would like to see more proactive communication when timelines shift. A few surprises this cycle could have been avoided with earlier flags."

For code quality issues:

• "The quality of their recent PRs was below their usual standard. I flagged [specific issues] in review, and similar patterns appeared across multiple PRs."
• "I think they would benefit from spending more time on testing and edge case coverage before submitting for review."

For collaboration problems:

• "In group discussions, they tend to [specific behavior] which can make it harder for others to contribute."
• "There were a few moments this cycle where better cross-team communication would have prevented rework."

For lack of ownership or initiative:

• "I noticed a pattern of waiting for explicit direction rather than proactively identifying what needs to be done."
• "I think they are capable of more ownership than they are currently taking. With more initiative on [specific area], they could have a significantly bigger impact."

What not to do

• Do not be anonymous and brutal. Even though peer reviews may be anonymous at some companies, write as if the person will read it and know it is from you. That keeps you honest and fair.

• Do not use absolute language. "They never" and "they always" are almost never true and immediately trigger defensiveness.

• Do not diagnose personal problems. "I think they are dealing with burnout" or "they seem checked out" is not your call to make. Stick to observable behavior and its impact.

• Do not pile on. If the person had one bad quarter, do not write as if they have always been this way. Focus on the review period.

• Do not skip the review. If you were asked to write it, write it. Declining to review someone because the feedback would be negative is a disservice to them, their manager, and the team.

The line between honest and cruel

Honest feedback describes behavior and impact. Cruel feedback attacks character and motivation.

"Their last three PRs had significant issues" is honest. "They clearly do not care about quality" is cruel. The first one can be addressed. The second one triggers an identity crisis.

Stay on the side of observable facts. If you catch yourself writing about what someone is (lazy, careless, difficult) rather than what they did (missed deadlines, skipped tests, interrupted others), rewrite it.

The best peer reviews combine genuine respect with genuine honesty. That combination is rare, which is why it stands out when someone does it well.

---

CareerClimb helps you document everything that matters for review season, from your own contributions to your peer observations. When it is time to write reviews, you are pulling from real data instead of scrambling to remember. Download CareerClimb and make review season easier.