How to give constructive feedback to a peer at work

Your manager can give you feedback because the org chart says so. You can't. When you give a peer feedback, there's no role behind you, no review cycle that licenses it, nothing that makes the conversation officially okay — which is exactly why it's the hardest direction feedback travels. Give it badly and you don't crush them the way a boss might; you do something quieter and longer-lasting. They decide you've overstepped, file you under "thinks they're my manager," and the relationship you have to keep working inside takes a small, permanent dent.

So most people don't give it at all. They watch a colleague keep doing the thing that's slowing the project down, say nothing, route around it, and let a thirty-second comment curdle into months of resentment. The avoidance feels like politeness. It's actually the most expensive option on the table — for the work, for the team, and eventually for the relationship you were trying to protect.

Why peer feedback breaks where manager feedback doesn't

When a manager gives feedback, the power gap does the structural work: the report can't easily wave it away, so the manager's risk is over-delivering — too much weight, too much threat. Peer feedback has the opposite failure mode. There's no role behind you and no consequence you control, so the risk isn't that they'll feel crushed. It's that they'll feel judged by someone with no standing to judge them. The reaction you're guarding against isn't tears. It's a raised eyebrow, a mental note, and a cooler working relationship for the next six months — the kind of damage that's slow, quiet, and much harder to undo than the over-delivered manager note.

That changes the whole job. A manager can, at a pinch, fall back on "I'm telling you this because it's my job to." You can't. The only thing that licenses you to comment on a peer's work is a goal you visibly share — and the entire craft of peer feedback is making that shared goal the obvious frame, so the feedback reads as two people on the same side of a problem, not one grading the other.

You can't evaluate a peer — so don't try

There's a useful distinction underneath all of this. Sheila Heen and Douglas Stone, in their work on feedback, split it into three kinds: appreciation (I see you), coaching (here's how to improve), and evaluation (here's where you stand). A manager can legitimately do all three. A peer can do exactly one — coaching — and gets into trouble the moment they slip into evaluation.

The trouble is that evaluation is the default register most of us reach for, because it's how we were given feedback our whole lives. "That presentation was too long" is an evaluation — a verdict on where the work stands. "I noticed people started checking their phones around the twenty-minute mark, and I wondered if the middle section could get cut" is coaching — information aimed at the next attempt. Same observation. One reads as a grade you have no business handing out; the other reads as a colleague trying to make the thing land better. The peer who confuses these is the peer nobody wants on their projects.

Anchor to the work, not the person

The fastest way to keep feedback in the coaching register is to anchor it to a specific behavior in a specific moment — never to character, and never to a pattern stated as a personality fact. The Center for Creative Leadership's guidance on feedback people can actually use is built on exactly this: situation, behavior, impact. With a peer it matters double, because anything that drifts toward "you're disorganized" or "you always do this" isn't just unhelpful — it's a status claim you don't have the authority to make, and it's the line that turns a useful comment into an offense.

"You're not a detail person" is a character verdict, and even if it's true, you've now said something about who your colleague is — which they will defend, because identity is not up for a peer's review. "The spec we shipped Tuesday was missing the error cases, and QA bounced it back twice — can we add a checklist step?" is about a specific artifact, a specific consequence, and a specific fix. There's nothing to defend, because you haven't graded them. You've pointed at a shared problem and proposed a move. That swap — verdict out, behaviour and next attempt in — is the whole trick, and it's worth seeing run across a dozen different moments before you need it in front of a colleague.

What it sounds like rewritten

The pattern is concrete enough to apply to almost any peer moment. Lead with the shared goal, name the specific thing, name its effect, and hand them the next step rather than the verdict.

1. 1

   Lead with the shared goal

   Open on us and the work — "I wanted us to get the design team's input" — so it reads as two people on the same side, not one grading the other.
2. 2

   Name the specific thing

   A behavior in a moment, never a trait. "The spec we shipped Tuesday was missing the error cases," not "you're not a detail person."
3. 3

   Name its effect

   The concrete consequence — "QA bounced it back twice" — so it's a shared problem, not a nitpick.
4. 4

   Hand over the next step, as a question

   End on a move phrased as an invitation: "can we add a checklist step?" A question between peers solves something together; a statement is a verdict you have no standing to deliver.

• Instead of: "You really dominated that meeting." Try: "I wanted us to get the design team's input today, but we ran out of time before they spoke — could we timebox the update next week so they get a slot?"
• Instead of: "Your code reviews are too nitpicky." Try: "When the review comes back with forty style notes, I lose the two that actually matter — would it help to flag the blocking ones separately?"
• Instead of: "You're hard to plan around." Try: "Twice this sprint I built on a date that moved, and it cost me a rework day — can we lock the handoff dates on Monday and treat them as fixed?"

Notice what every rewrite does. It opens on us and the work, not on you. It points at a moment, not a trait. And it ends with a question, because a question between peers is an invitation to solve something together, while a statement is a verdict delivered downward — and you don't have downward.

Make it mutual, or don't give it

The single move that disarms peer feedback faster than any phrasing trick is reciprocity. Feedback between equals lands cleanest when it flows both ways, because the moment it's mutual it stops being "I'm evaluating you" and becomes "we check each other's work." The peer who asks "and tell me where I'm slowing you down" right after offering a note has changed the entire transaction. It's no longer a one-way judgment from someone pretending to a standing they don't have; it's two colleagues doing the normal maintenance of a working relationship.

This is the mirror of a skill we cover from the other side — how to ask peers for feedback — and the two are the same loop seen from opposite ends. The peer relationships where feedback flows easily aren't the ones with the most diplomatic people. They're the ones where both sides have made it ordinary, low-stakes, and reciprocal, so that no single comment carries the weight of a rare and dangerous event.

When to hold it

Restraint is part of the craft, not a failure of nerve. Some peer feedback genuinely isn't yours to give. If the issue is one your shared manager owns — a performance problem, a missed commitment that's really a management matter — routing it through a peer comment isn't candor, it's overstepping, and it'll read that way. And if you only have the standing to say it because you're frustrated rather than because you share a goal, that's the signal to wait. Peer feedback works on relationship capital; spend it on the things that actually move shared work, not on every irritation, or you become the colleague whose notes everyone learns to tune out.

Where Mirorly fits

Sideways is the direction where the words carry everything, because there is no authority underneath them and no process to hide behind. That is what Mirorly is built for: the conversation you keep rehearsing and never having, prepared rather than improvised. Fifteen of its forty-five situations point sideways — a peer who will not reply and your work is stuck behind them, one who took credit for something you did together, one whose request keeps growing well past the original ask — and each arrives worded three ways: opening with a question, opening with the point, or written down for the record. None of the three hedges, because hedging is one of the things it flags in your own draft. It also gives you the part no framework does: what to say when they deny it happened, bury you in explanation, or say nothing at all.

Then the quiet thing that happens once you get good at this: your colleagues start experiencing you as someone who evaluates their work — even gently, even well — and the better you get, the more they hold back what they see in you. The skill cuts both ways, and almost nobody is equally good at giving and receiving. Answering a set of questions about how you actually work is the version that needs nobody's participation but your own; wording one request that doesn't come back as a compliment is where it starts when you want it from a peer — and asking first is what makes it reciprocal, which is the same thing that makes peer feedback work in the first place.

Common questions

The one-line summary

Peer feedback has no authority behind it, so it only works as coaching toward a shared goal — anchored to a specific behavior and its impact, ended with a question, and made mutual — and the fastest way to earn the standing to give it is to keep asking for it back.