How to Write 360 Feedback That Actually Helps (With Examples)

Most 360 feedback reads like this: “Good team player. Communicates well. Could improve time management.”

The reviewer spent two minutes. The subject learns nothing. The review cycle produced data without insight.

Writing useful feedback isn’t about writing more. It’s about writing specifically. One concrete observation beats ten generic adjectives.

The Behavior-Situation-Impact Framework

Every piece of useful feedback follows a pattern: what happened, where it happened, and what effect it had.

Weak: “Great communicator.”

Strong: “During the product launch in January, she proactively updated the team on blockers every morning. This prevented two potential delays that would have pushed the release by a week.”

The strong version names a specific behavior (daily blocker updates), a specific context (product launch), and a specific impact (prevented delays). The subject knows exactly what to keep doing and why it matters.

Real Examples by Category

Strengths

Instead of: “Good at mentoring.”

Write: “When the new developer joined in November, he pair-programmed with them three times a week for the first month. The new hire shipped their first feature independently by week five — faster than anyone else in the last two years.”

Instead of: “Strong technical skills.”

Write: “She identified a query performance issue that the rest of the team had attributed to expected latency. Her fix reduced page load time from 4 seconds to 200 milliseconds for the accounts dashboard.”

Growth Areas

Instead of: “Needs to delegate more.”

Write: “During the Q3 sprint, he took on the database migration, the API redesign, and the client demo prep simultaneously. The migration deadline slipped by three days. Handing off the demo prep to a teammate who had capacity would have kept the migration on track.”

Instead of: “Communication could improve.”

Write: “The design decision to switch frameworks was shared in a Slack thread at 11pm. Half the team missed it and started Monday with outdated assumptions. Bringing significant decisions to the daily standup — even briefly — would prevent this.”

Ratings

When a question asks for a 1-5 rating alongside text, the text should explain the rating:

Rating 4/5 on Collaboration: “Consistently available for code reviews and responds within the same day. The rating isn’t a 5 because cross-team handoffs sometimes miss context — the receiving team has to ask follow-up questions more often than they should.”

This gives the subject a clear picture: strong collaboration within the team, room for improvement on handoffs.

What to Avoid

Personality judgments. Feedback should describe behaviors, not character. “She’s disorganized” is a judgment. “Meeting notes from her sessions are inconsistent — some sessions have detailed notes, others have nothing” is observable behavior.

Guessing at intentions. “He doesn’t care about code quality” assumes motivation. “Three of his last five pull requests were merged without addressing review comments” describes a pattern.

Recency bias. The last two weeks aren’t representative of six months of work. Before writing, mentally scan the full review period. If you can only recall recent events, that’s a signal to write what you remember and note the gap honestly.

Comparative feedback. “She’s better than the rest of the team at documentation” isn’t useful. It positions the subject relative to others rather than against their own potential. Focus on what they do and what they could do — not how they rank.

Softening to the point of uselessness. “Maybe they could possibly consider potentially thinking about delegating a tiny bit more” communicates nothing. Be direct: “Delegating the demo prep would have kept the migration on schedule.” Kindness isn’t vagueness — it’s honesty delivered with respect.

The Two-Minute Check

Before submitting, read your response and ask:

1. Could this apply to anyone? If yes, it’s too generic. Add a specific situation.
2. Would the subject know what to do differently? If no, your growth area needs a concrete suggestion.
3. Is this about behavior or personality? If personality, rewrite around observable actions.

Good feedback takes five minutes per person, not two. That three-minute difference is the gap between feedback that changes behavior and feedback that gets filed away.

Why Anonymity Makes Honesty Possible

The reason most feedback reads as vague praise isn’t laziness. It’s self-protection. When reviewers believe their responses might be identified — through writing style, timing, or small team dynamics — they optimize for safety over truth.

Structural anonymity (threshold-based reveal, synthesis-only results, role separation) removes the calculation. When you genuinely trust that your feedback can’t be traced back to you, you can write “The migration deadline slipped by three days because you didn’t delegate” instead of “Time management could improve.”

The feedback itself gets better when the system makes honesty safe.