How to Write a Peer Review for a Coworker

It is 10pm on a Thursday. Peer reviews are due tomorrow. You have six of them to write, plus your own self-review, and you are staring at a blank text box trying to figure out what to say about someone you paired with on one project four months ago.

So you write "Great to work with. Strong collaborator. Would love to work with them again." Submit. Move on to the next one.

That review is worthless. You probably do care. The problem is that nobody taught you what a useful peer review actually looks like or why it matters.

Your peer review gets read in the room where promotions happen

Most engineers treat peer reviews like a chore to check off. That is a mistake.

At most big tech companies, peer feedback gets pulled directly into calibration. Your manager reads it. Other managers hear it. At Google, peer feedback is one of the inputs that calibration panels use when deciding ratings. At Amazon, peer data feeds into the OLR process. At Meta, it shows up in the PSC packet.

When you write "strong collaborator" with nothing behind it, your manager has nothing to quote. When you write something specific, like "She identified a data integrity issue in the billing pipeline that nobody else caught, which prevented an estimated $200K in incorrect charges," that becomes ammunition.

Your words end up in rooms you will never enter. Write them like they matter, because they do.

What separates a useful peer review from a useless one

A Zenger Folkman study of over 2,500 employees found that 57% of employees actually prefer corrective feedback over praise. By a roughly three-to-one margin, people believe honest, constructive input improves their performance more than positive feedback alone.

Yet most peer reviews read like a greeting card. "Pleasure to work with." "Always willing to help." "Great communicator." These tell the reader nothing. They cannot be used in calibration. They do not help the person grow.

The difference between a useful review and a useless one is specificity. Name what happened. A specific project, a particular decision, an observable behavior. "Redesigned the caching layer" beats "made technical improvements" every time.

Then connect it to impact. Say why it mattered. What changed because of what they did? "Reduced API latency by 40%, which unblocked the mobile team's launch" is a review that carries weight in a calibration room.

And be honest. Honest does not mean brutal. It means real. If someone struggled with communication during a cross-team project, saying so with care is more helpful than pretending everything was fine. Research on the feedback sandwich shows that burying criticism between two compliments actually makes the criticism less likely to land. Primacy and recency effects mean people remember the first and last thing you say, so the buried middle gets lost.

A structure that works for any peer review

You do not need a framework with an acronym. You need three paragraphs that answer three questions.

Paragraph 1: What did they do? Name a specific project, initiative, or behavior. Anchor it in time and context. "During the Q3 migration to the new auth service" is better than "throughout the review period."

Paragraph 2: Why did it matter? Connect their work to a result. Team velocity, user impact, risk reduction, unblocking other teams, mentoring a junior engineer through a hard problem. If you can attach a number, do it. If you cannot, describe the counterfactual: what would have happened if they had not done this.

Paragraph 3: What should they keep doing, or what could they work on? This is where you either reinforce a strength ("Her instinct for catching edge cases before they hit production is something the team relies on") or offer a growth area ("His technical solutions are strong, but he sometimes moves forward without getting buy-in from stakeholders, which created friction during the API redesign").

That is it. Three paragraphs. You can write this in ten minutes if you have a concrete example in mind. If you need specific language to get started, the peer review examples article has 40+ phrases organized by situation that you can adapt.

Before and after

Weak review:

"Alex is a great engineer and a strong team player. He is always willing to help and consistently delivers high-quality work. I enjoy working with him."

This says nothing. It could describe anyone. It gives the manager zero material for calibration.

Strong review:

"Alex led the migration of our notification service from a polling model to a push-based architecture during Q3. The project had been stuck for two quarters before he took it on. His approach of breaking it into three phases with clear rollback points meant we shipped with zero downtime, and the team adopted his phased migration pattern for the next two service migrations. One area where Alex could grow: during the project, some stakeholders in the mobile team felt blindsided by API changes. Getting alignment earlier in the process would make his already strong execution even more effective."

Same person. Same review cycle. The second version actually helps.

How to handle the situations that make peer reviews hard

When you barely worked with someone

This is the most common problem. You are on a reviewer list for someone you interacted with for two weeks on a cross-team project.

Do not fake it. A short, honest review is better than a long, vague one. Focus on what you actually observed:

• How they communicated in shared channels or meetings
• Whether they followed through on commitments
• How they handled disagreements or blockers
• The quality of their code reviews, documents, or design proposals you saw

If you truly have nothing substantive, it is OK to write a shorter review and say "My interaction with them was limited to the X project in Q2, so I can only speak to that scope." Reviewers and managers understand this.

When a friend is not performing well

This is where most people go vague. You like someone personally, so you write a glowing review that papers over real problems. That does not help them. If the concerns are serious, the guide on writing a peer review for someone you have concerns about walks through exactly how to frame honest feedback without damaging the relationship.

The question to ask yourself: if the situation were reversed, would you want your friend to tell you? The Zenger Folkman data says yes. 92% of employees agree that honest negative feedback, delivered appropriately, improves performance.

You can be kind and honest at the same time. Lead with what you respect about them, then name the specific thing that held them back. "His debugging instincts are among the best on the team. During the Q3 incident, though, he took over the investigation without looping in the on-call engineer, which duplicated effort and delayed the resolution. Tightening that handoff process would make him more effective in high-pressure situations."

That is not cruel. That is useful.

When someone is great at their job but difficult to work with

Separate the work from the interpersonal. You can acknowledge strong output while noting collaboration friction. Calibration committees care about both.

"She consistently ships high-quality features ahead of schedule. Her technical judgment is reliable. In cross-functional work, though, her tendency to make decisions unilaterally without documenting the reasoning created confusion for the design and PM teams during the dashboard redesign. When she did write up her decision rationale in the RFC for the notifications feature, the collaboration went much smoother."

Notice the pattern: name the problem, but also point to a time when they did it well. That makes the feedback actionable instead of just critical.

Mistakes that make your peer review worthless

Writing about personality instead of behavior. "She's really nice" or "He has a great attitude" is not feedback. It is a character reference. Calibration committees want to know what someone did and how it affected the team.

Copying the same review for everyone. If your reviews for five different people are interchangeable, you have written five useless reviews. Each person did something different. Write about that.

Skipping growth areas entirely. An all-positive review with zero constructive feedback reads as either lazy or political. Managers know nobody is perfect. If you cannot name one area where someone could improve, you have not thought hard enough.

Three focused paragraphs beat eight paragraphs of filler. Calibration committees are reading dozens of reviews. Do not write a novel. Respect their time.

One more: do not wait until the last hour. When you rush, you default to generalities. The engineers who write the best peer reviews keep a running note throughout the review period. Even two bullet points per person gives you something concrete to work from when the form opens.

Start tracking so review season is not a scramble

The reason peer reviews feel so painful is the same reason self-reviews feel painful: you cannot remember what happened three months ago. When you log wins and observations throughout the review period, writing reviews becomes a matter of pulling from notes instead of pulling from a foggy memory.