PerfCopilot
Flat editorial illustration in deep indigo and soft violet on off-white: a notebook, a pen and a few ruled lines, with two linked circles and an open speech-bubble outline set off to one side. No text and no people.

Peer feedback examples specific enough to quote in a review

Peer feedback usually arrives as adjectives. "Great teammate." "Always helpful." "Could communicate more." A manager reads it, nods, and then cannot use a single line of it, because none of it names a thing that happened. The response was honest. It just was not specific, and a review built on adjectives is a review the employee cannot check and cannot argue with.

The fix is not a longer form. It is asking a smaller question and showing people what a usable answer looks like. Below are the questions worth asking, the weak and strong version of the same response side by side across five competencies, and what changes in a review draft when the strong version is the one that arrives.

Honest trade-off: Peer feedback is not derived from a work artefact. Like a manager's own notes, it is one person's account of what they saw, and nobody can audit an impression the way a closed ticket can be audited. That is exactly why it is valuable, because it sees what no system logs, and exactly why it corroborates a rating rather than deciding one.

By Samira Bahmanyar · HR Manager

Key Takeaways

  • Ask for a moment, not a verdict. "What did they do that you would want copied?" produces quotable material. "Rate their collaboration" produces adjectives.
  • Three or four peers who worked with the person closely beats ten who barely did.
  • Let the peer decide whether their name travels with their words. Anonymity is theirs to choose, not the manager's to assign.
  • Peer responses belong in the competencies no log can see: collaboration, mentoring, judgement when a project goes wrong.
  • A peer rating is corroboration, not the number a rating is built from.

Try it on your own data: PerfCopilot emails each nominated peer a single-use link, collects their response, and folds it into a cited, bias-checked review draft next to the work itself. Generate a performance review or read the peer feedback setup guide. Free up to 5 seats, no seat minimum.

What peer feedback is for, and what it is not for

Peer feedback earns its place by covering what no system records. A repository shows that a pull request was reviewed; it does not show that the reviewer spent half an hour first explaining why the original approach would not hold. A ticket tracker shows a ticket closed; it does not show who went and found the three people it was blocking. A CRM shows a deal closed; it does not show which colleague handed over the relationship that made it possible.

So ask peers about the things only a person sitting nearby can see, and let the work itself answer everything else. PerfCopilot's own default competency presets are weighted that way: for an engineering individual contributor, peer feedback carries 0.5 of the Collaboration competency against 0.3 for chat activity and 0.2 for manager notes, and only 0.2 of Technical Execution, where code and tickets do the work. The weights are a starting point a manager can change, and the direction of them is the point.

Peer feedback answers this wellAnd this badly
How someone behaves when a project goes sidewaysHow much someone shipped
Whether help was offered before it was asked forWhether deadlines were met
Whether disagreement stayed about the workCycle time, throughput, volume
Who a person made better at their jobAnything the peer was not present for

The four questions worth asking

One number and three open questions. That is the entire form PerfCopilot sends a nominated peer, and the shape matters more than the wording.

FieldWhat it asksWhy it is shaped that way
Overall rating, requiredA single number from 1 to 5, labelled on the form from "needs significant improvement" to "exceeds expectations"The scale is written down so the peer is not inventing one. It is the only required field, so a busy peer still submits something
"What does this person do well?"Open text, optionalPrompts for specifics: projects shipped, behaviours observed, moments where they raised the bar
"Where could they grow?"Open text, optionalPrompts for concrete moments over abstract critiques
"Anything else?"Open text, optionalThe caveat field. This is where "I only worked with them for a month" goes, and that sentence changes how the rest should be read

Three open fields is deliberately few. That is a judgement rather than a measurement: a long form tends to get the first answer or two and then trail off, and a half-finished form is worse than a short one because it looks like a complete picture. The invitation says it takes about five minutes, and the form should be able to keep that promise.

Peer feedback examples: the weak and the strong version

Every pair below is the same person, the same opinion, and the same amount of goodwill. The difference is whether the response names an occasion.

Collaboration

Weak responseStronger response
"Great to work with, always willing to help.""When the billing migration slipped, she rewrote the rollback plan with me on a Friday afternoon rather than letting it land on the on-call engineer. She did not own that work and did not mention it afterwards."
"Good team player.""He noticed my design doc had been sitting unreviewed for a week, read it, and left the kind of comments that told me he had actually opened the code."

Communication

Weak responseStronger response
"Communicates well.""Her project updates are the only ones I do not have to re-read. She leads with the decision and puts the reasoning underneath, so I can stop reading when I have what I need."
"Could communicate more.""Twice this quarter I found out a dependency had changed from someone else. The information existed, it just stayed in his head until asked. A two-line note in the channel would have saved a day both times."

Mentoring and knowledge-sharing

Weak responseStronger response
"Very knowledgeable, helps juniors.""He paired with our new hire for the first three weeks instead of pointing her at the docs. She shipped her first change in week two, which is faster than I managed, and she now answers questions in that channel herself."
"Shares knowledge.""After the outage he wrote up what went wrong in plain language and did not make anyone look stupid in it. I have sent that document to two new starters since."

Ownership when something breaks

Weak responseStronger response
"Reliable under pressure.""When the import job failed over the weekend she found it before the customer did, fixed it, and had a one-paragraph summary ready on Monday morning with the part she got wrong included."
"Sometimes drops things.""Two of the follow-ups from our planning session never happened and I did not hear that they would not. Either would have been fine to drop on purpose; the surprise was the problem."

Cross-functional partnership

Weak responseStronger response
"Works well with other teams.""He sat in on three of our support calls without being asked, then changed the error message that was generating most of them. Our ticket volume on that flow has been quiet since."
"Hard to get time with.""Twice I needed a decision from her team and waited a week each time. She was not the bottleneck, but she was the person who could have said who was, and she did not."

What the strong versions all have

Three properties, and they are easy to ask for by name:

  1. An occasion. A week, a project, an incident, a meeting. Something with edges.
  2. An observable behaviour. What the person did, not what they are like.
  3. A consequence. What was different afterwards for the team, the customer or the colleague writing it.

A response with all three can be quoted in a review and defended in a calibration room. A response with none of them is a vote, and a vote is not feedback.

The growth half is where people go quiet

Most peers write something usable under strengths and then put "nothing, they're great" under growth, which helps nobody. Two framings reliably unlock it. The first is to ask what the person should stop doing rather than what they are bad at. The second is to ask what you would warn a new teammate about, kindly, before they started working with them. Both are answerable without passing judgement on someone, which is the part people are avoiding.

How to ask so the strong version is what arrives

The mechanics in PerfCopilot follow that order. A nomination is keyed to one employee, one review cycle and one peer email, so the same person cannot be invited twice for the same cycle. What that key does not do is pin the response to that one cycle, and it is worth knowing that it does not. A submitted response is deliberately copied into every active review period whose window covers it, so a reply written during a week also reaches the month and the quarter that contain that week. No review draft has to exist first, so a manager can invite peers the day a cycle opens and generate the draft weeks later. The peer gets an email with a link that is unique to them, needs no account to use it, and the link stops working once it has been used.

Anonymity: the peer chooses, not the manager

On PerfCopilot's form the anonymity checkbox is ticked by default and the peer can untick it. That default is a judgement about who carries the risk: the person writing honestly about a colleague has more to lose than the person reading it.

Both choices cost something, and it is worth being straight about which. An anonymous response gets more candour and cannot be followed up, so a manager who wants the detail behind a sentence has nowhere to go. A signed response can be explored in a conversation and will be gentler. Letting the peer pick per response means a team can have both in the same cycle.

The choice is then enforced everywhere the response is read rather than just where it is displayed. When a response is anonymous, the name is dropped from the review prompt, which shows "(anonymous)" in its place, from the dashboard summary a manager sees, and from the signal row written alongside it. The name is absent rather than hidden, which is a different and better thing.

What happens to a response once it is submitted

A submitted response reaches the draft as a labelled block, not as prose mixed in with everything else. PerfCopilot assembles it as a PEER / 360 FEEDBACK section listing the number of responses and their average rating, then each response in turn with its rating, its strengths, its growth note and its caveats, attributed by name or marked anonymous. The model writing the draft is instructed to cite the source in brackets after each key claim, so a sentence that came from a colleague arrives in the draft marked [Source: Peer Feedback] rather than blended into a sentence about commits.

That marking is the whole point. An employee reading "you are seen as hard to reach by other teams" cannot do anything with it. An employee reading the same sentence with its source attached knows which kind of evidence it is, and can say that it is wrong.

One thing peer feedback is deliberately not used for: comparison between people. PerfCopilot works out a historical median for several signal sources, drawn from every review the organization has previously submitted, so a manager can see whether a number is normal here rather than guessing. Peer ratings are excluded from that calculation on purpose. An average of four impressions is not comparable between two employees who have four different peers, and treating it as if it were would turn a popularity sample into a performance curve.

Where peer feedback should not decide anything

Where this fits with the rest of the cycle

Peer feedback is one of several signal sources, five on the free plan and eleven on the top tier, and it reads best next to the others. The performance review phrases guide has competency framings a manager can reuse once the peer responses are in. How to write a performance review covers the evidence-first method the peer block plugs into. How to run a calibration meeting is where a quoted peer response either holds up or falls apart, and reducing bias in performance reviews covers what the screen on every draft is looking for, including the language patterns that show up in peer comments more than anywhere else.

If the employee is writing their own side of it, the brag document method and the self-review examples are the companion pieces.

Related


Try it free. PerfCopilot invites the peers, collects the responses, and writes a review draft where every line is traceable to the artefact or the colleague it came from. Start free, or see the pricing. Free up to 5 seats, no seat minimum.

By Samira Bahmanyar · HR Manager

Last updated: 2026-11-04.

Frequently asked questions

What are good peer feedback examples for a performance review?
A usable peer response names an occasion, an observable behaviour and a consequence. "Great teammate" has none of the three. "When the billing migration slipped, she rewrote the rollback plan with me on a Friday rather than letting it land on the on-call engineer" has all three, and can be quoted in a review and defended in a calibration meeting. Ask for a moment rather than a verdict and you get the second kind.
How many peers should give feedback for one review?
Three or four people who shared real work with the employee, rather than ten who shared a channel. Breadth makes the summary look thorough while making every individual response vaguer, because a peer who barely worked with someone can only offer an impression. Pick for overlap with the work, and avoid picking only the colleagues the employee gets on with: that sample measures likeability and reports it as collaboration.
Should peer feedback be anonymous?
Let the peer decide. On PerfCopilot's feedback form the anonymity checkbox is ticked by default and the peer can untick it, because the person writing honestly about a colleague carries more risk than the person reading it. An anonymous response gets more candour and cannot be followed up; a signed one can be explored in conversation and will be gentler. When a response is anonymous the name is dropped from the review prompt, the manager's summary and the stored signal row, so it is absent rather than hidden.
What questions should you ask a peer for a performance review?
One number and three open questions is enough. PerfCopilot asks for an overall rating from 1 to 5 against a written scale, then "What does this person do well?", "Where could they grow?" and "Anything else?", with only the rating required. The last field is where caveats like "I only worked with them for a month" go, and that sentence changes how the rest should be read. A longer form gets abandoned halfway, which looks like a complete picture and is not one.
Can peer feedback decide a performance rating?
It should not. An average of four colleagues' impressions carries no error bars and a lot of apparent confidence. PerfCopilot works out a historical median for several signal sources, drawn from the reviews the organization has previously submitted, so a manager can see whether a number is normal there, and peer ratings are deliberately excluded from that calculation: an average of four impressions is not comparable between two employees who have four different peers. Read peer feedback next to the work, not instead of it.