How to run a 360 peer review for a small team

When I became a manager of software engineers in 2018, I quickly found it surprisingly hard to know how much my team trusted each other, or me. One-to-ones only showed me a slice of how each person worked. The people who really knew were their teammates.

So in 2021 I started trialling anonymous 360 peer reviews myself, starting with people on probation. By 2022 the questions had settled on two things: whether teammates trust each other, and whether they trust each other with the actual responsibilities of their role. This guide is everything I’ve learnt doing that, written for a manager or team lead with somewhere between three and twenty people who wants to run a 360 without buying an enterprise HR platform.

What a 360 peer review is (and isn’t)

A 360 peer review gathers feedback about one person from the people around them: teammates, people in other teams they work with, and sometimes their manager. It’s called a 360 because the feedback comes from all sides rather than just from above.

In a small team, a 360 isn’t a grading exercise. It’s a structured, anonymous way to say the things that are hard to say face to face. Lydia, a software engineer who has been through these reviews, put it better than I can:

That’s the job a 360 does well. It’s not a replacement for one-to-ones, retrospectives, or simply talking to each other. It catches what those miss.

Before you start: decide what the review is for

The single most important decision comes before you write a question: is this review for development or for pay?

My strong advice is to keep it for development. Use 360 feedback to help someone grow, and keep it well away from bonuses. The moment a score decides money, people start managing the score instead of the work. Goodhart’s Law sums it up: “when a measure becomes a target, it ceases to be a good measure.” Reviewers soften what they say about friends, and the person being reviewed starts campaigning for good ratings.

That doesn’t mean the results can never appear in a performance conversation. Where a performance review is purely about feedback and not tied to a bonus, I’ve used trust scores alongside team KPIs and OKRs, because they’re a clear and relevant measure. Just remember that the same person can score quite differently in different teams, so treat a score as a conversation starter rather than a verdict.

Whatever you decide, tell the team up front. People give more honest feedback when they know where it’s going.

Step 1: Go first

If you’re introducing 360s to a team that hasn’t had them, run one on yourself before anyone else. It shows the team you’re willing to hear the same kind of feedback you’re asking them to hear, and it lets you find the rough edges in your process while the only person affected is you.

Step 2: Write down what the role actually involves

Generic questions get generic answers. “Is Sam a good communicator?” invites a shrug. Feedback becomes useful when it’s tied to what the person is actually there to do.

So before you send anything, write down three to six responsibilities for the person’s role, in plain language. For a software engineer, that might look like:

• Deliver features that meet the agreed requirements
• Review code constructively and promptly
• Write tests that give the team confidence to release
• Share knowledge and help others to grow

Then write down your team’s or organisation’s values, again in plain language. “Be open and honest”, “Take ownership”, and “Put the customer first” are the kind of thing I mean. If you don’t have written values, a short conversation with the team about how you want to work together is a good place to start, and it’s useful in its own right.

Writing responsibilities down has a side benefit: it often reveals that the person and their manager have slightly different ideas about what the job is. Better to find that out now than in the results.

Step 3: Keep the questions few and focused on trust

Long questionnaires are the quickest way to kill a 360 in a small team. In a team of six, each person may be asked to review five colleagues, so every extra question is multiplied. I’ve settled on five questions, and I haven’t felt the need for more:

1. In terms of values, I trust them to… rated against each of your values.
2. In terms of the responsibilities in their role, I trust them to… rated against each responsibility.
3. How often does their engagement with the team and the work impress you?
4. When have they impressed you and what did you admire about them? (free text)
5. When could they have helped you or the team more and what could they have done? (free text)

I frame the rating questions around trust rather than skill on purpose. “Do I trust them to review code constructively and promptly?” is something any teammate can answer from their own experience. “How good are they at code review?” asks them to be an assessor, which most people are rightly uncomfortable with.

For the ratings, I use a five-point scale of how often: Infrequently, Sometimes, Unsure, Regularly, and Almost always. Including “Unsure” matters. Without it, a reviewer who hasn’t seen someone do a particular thing is forced to guess, and guesses look exactly like real answers in the results.

The two free-text questions are where most of the value lives. Mark, a manager who has used these reviews, says the real benefit for him is the answers to what the person could do to help more and what people admire most about them:

Asking for a specific moment (“when have they…”) rather than a general opinion makes the answers far more concrete. Asking for one positive and one improvement keeps the review balanced without anyone having to try.

If you’d like to see how these questions look to a reviewer, the example review shows the exact form.

Step 4: Choose the reviewers

In a small team, choosing reviewers is mostly common sense, but a few things help:

• Pick people who work with them regularly. Teammates first, then people from other teams they collaborate with. Someone who sees them once a month can’t say much about how they review code.
• Aim for at least three, ideally four to six. Fewer than three makes anonymity nearly impossible and lets one strong opinion dominate. Trust Reviews won’t produce a summary until at least three people have responded, for exactly this reason.
• Include people outside the immediate team where you can. In a very small team, adding a couple of regular collaborators from elsewhere helps both honesty and anonymity.
• Don’t review everyone in the same week. If you’re rolling out to the whole team, stagger the reviews over a few weeks so nobody gets five forms on the same Monday.

Step 5: Protect anonymity, and explain how

Anonymity is harder in a small team. When there are only four possible reviewers, people worry their phrasing will give them away, and they’re not wrong to worry. If you can’t protect anonymity, you won’t get candid feedback.

Whatever tools you use, a few principles go a long way:

• Don’t store who said what alongside what they said.
• Don’t show raw comments to the person being reviewed. Combine and rephrase them so individual writing styles disappear.
• Require a minimum number of responses before anyone sees results.
• Ideally, the person running the review shouldn’t see raw responses either, only the combined summary.

Then tell reviewers exactly how their answers are protected, in plain words, before they start. A vague “this is anonymous” isn’t very reassuring. A specific explanation of what is and isn’t kept is.

This is honestly the part that pushed me to build a tool. Doing it by hand with forms and spreadsheets meant I could see every raw answer and had to rewrite them myself, which was slow and put a lot of trust in me. In Trust Reviews, reviewer details aren’t stored with their feedback, the free-text answers are summarised together with AI in its own words, and the person who scheduled the review only ever sees the summary.

Step 6: Send it with a clear close date

When you send the review, keep the message short: who it’s for, roughly how long it takes (with five questions, a few minutes), how it’s kept anonymous, and when it closes. A week or two is usually plenty. Without a close date, a 360 tends to drift.

A gentle reminder a couple of days before it closes helps people who meant to do it and forgot. Resist chasing individuals by name, as it undermines the sense that nobody is watching who has or hasn’t responded.

Step 7: Read the results before you share them

When the review closes, read the summary yourself first. You’re checking two things: that the feedback is appropriate for the person to see, and that you understand it well enough to talk about it. Pay particular attention to the scores and any AI-written summaries, as no summary is perfect and some things may need context.

Usually the summary can be shared in full. Occasionally, the feedback is particularly negative. In those cases, I think it’s wiser to share only the most important and actionable parts, agree on what to work on, and run another review in two or three months once they’ve had time to act on it. Dumping a pile of hard feedback on someone all at once rarely helps them improve.

You can see what a finished summary looks like, with scores and combined comments, on the example summary.

Step 8: Talk it through in a one-to-one

A 360 summary is a starting point for a conversation, not the conversation itself. Ideally, you and the person reviewed both have the summary and discuss it together in a one-to-one. A structure that works for me:

1. Start with what people admire. It’s usually more than the person expects, and it’s genuinely motivating.
2. Ask them what surprised them, before offering your own view.
3. Go through the areas to improve and look for themes rather than individual comments.
4. Agree one or two specific actions. Not ten. One or two they can actually do in the next couple of months.

Remind them that all feedback contains opinions, and opinions aren’t always right. It’s ultimately up to them what they believe and act on. What they should appreciate is the time and care their colleagues put into giving it.

Step 9: Close the loop with the reviewers

People keep giving honest feedback when they can see it makes a difference. A short thank you to the reviewers goes a long way, and if the person reviewed is comfortable with it, sharing one thing they’re going to work on shows the team their effort was worth it.

Step 10: Make it a rhythm, not an event

A single 360 is a snapshot. The real value comes from repeating it, so people can see whether things have changed. Mark noted that the scores on their own can feel “slightly arbitrary”, but that they “can give some insight into the progress someone is making”. Progress only shows up when you have more than one review to compare.

How often depends on your team, but here’s what I’d suggest:

• During probation: for a six-month probation, one review after two months and another after four. That gives two chances for feedback and action before any decision is made.
• After a tough review: another review two or three months later, once they’ve had time to act on it.
• Otherwise: a couple of times a year per person is plenty for most small teams. Often enough to show progress, rarely enough that nobody gets tired of it.

Common mistakes to avoid

• Instead ofTying it to bonuses, and getting kinder, less useful feedback.
  →
  TryKeeping it for growth, and saying so up front.
• Instead ofA long questionnaire multiplied by every reviewer.
  →
  TryFive short questions.
• Instead ofGeneric questions about being a “good communicator”.
  →
  TryTrust in the person’s real responsibilities and your values.
• Instead ofOne or two reviewers.
  →
  TryAt least three, so anonymity and balance hold up.
• Instead ofSharing raw comments that give writing styles away.
  →
  TryA combined, reworded summary.
• Instead ofA review that goes nowhere.
  →
  TryOne or two actions, followed up in one-to-ones.
• Instead ofStarting with someone else.
  →
  TryGoing first yourself.

Can you do this with free tools?

Yes, and I did for a few years. A form tool and a spreadsheet will get you surprisingly far for one or two reviews. Where it gets hard is everything around the form: sending individual links, keeping reviewer details away from answers, waiting for enough responses, combining and rewording comments so nobody can be identified, and doing it all again next quarter for every person.

By 2024 I needed to automate it, which is how Trust Reviews came about. It schedules the review, sends each reviewer an anonymous link, and writes the summary once enough people have responded. It’s deliberately small and focused on exactly the process in this guide. Whether you use it or not, I hope the steps above help you run a 360 your team finds genuinely useful.