
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 well | And this badly |
|---|---|
| How someone behaves when a project goes sideways | How much someone shipped |
| Whether help was offered before it was asked for | Whether deadlines were met |
| Whether disagreement stayed about the work | Cycle time, throughput, volume |
| Who a person made better at their job | Anything 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.
| Field | What it asks | Why it is shaped that way |
|---|---|---|
| Overall rating, required | A 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, optional | Prompts for specifics: projects shipped, behaviours observed, moments where they raised the bar |
| "Where could they grow?" | Open text, optional | Prompts for concrete moments over abstract critiques |
| "Anything else?" | Open text, optional | The 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 response | Stronger 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 response | Stronger 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 response | Stronger 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 response | Stronger 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 response | Stronger 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:
- An occasion. A week, a project, an incident, a meeting. Something with edges.
- An observable behaviour. What the person did, not what they are like.
- 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
- Nominate people who were actually there. Three or four colleagues who shared real work beats ten who shared a channel. Breadth makes the summary look thorough and makes every individual response vaguer.
- Do not nominate only the friendly ones. The sample is the result. If every peer is someone the employee gets on with, the exercise measures likeability and reports it as collaboration.
- Ask early in the cycle, not at the end of it. Peers reply in days, not minutes, and a response written in a rush is a response made of adjectives.
- Say what happens to it. A peer who does not know whether their words will be read by the subject writes for the safest possible outcome.
- Never ask for a ranking. "Is she stronger than the rest of the team?" is a question nobody can answer honestly and everybody can answer politically.
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
- It is not a rating. Averaging four colleagues produces a number with no error bars and a great deal of confidence. Read it next to the work, never instead of it.
- It is not a popularity measure, so stop reading it as one. The quiet engineer who unblocks people and never posts about it scores badly on a sample drawn from a chat channel.
- The peer sees no evidence. PerfCopilot's feedback form shows who is asking and who it is about: the inviting manager's name, the peer's own name, the subject's name and role, and which review cycle is being asked about. No signals, no metrics, no draft. A peer is answering from memory, which is both the value and the limit of the thing.
- A late reply shows on the dashboard but not in that cycle's draft. The places PerfCopilot reads peer responses do not treat a late one the same way, and the difference is worth knowing before you go looking for a response that seems to have vanished. The manager-facing peer panel and the signals list both pull a reply that arrived after the period closed back to the period's last day, on the stated grounds that peers often answer a day or two late. The generated draft does not: it selects responses by the date they were actually written, so a reply that landed after the period's end is left out of that period's draft and reaches the overlapping monthly or quarterly draft instead. The visible effect is a panel that says four responses next to a draft that cites three, with nothing on the page explaining the gap. Ask early, chase once, and check the panel count against the draft before you send it.
- A bad-faith response can be removed, visibly. The employee's manager of record can delete a nomination, which removes the response and every copy of it across cycles, and the deletion is written to the audit log with who did it and what state it was in. A removal nobody can see is not a safeguard.
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
- Performance review phrases for managers
- How to run a performance calibration meeting
- How to reduce bias in performance reviews
- The brag document method
- Peer feedback setup guide
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.