360 feedback questions by role

How to choose 360 feedback questions

Good 360 questions share three traits: they ask about behavior the reviewer has actually seen, they are specific enough to answer in a sentence, and they are the same for everyone in the same role so the answers can be compared.

Aim for eight to twelve questions in total. Beyond that, reviewers start to skim, and the quality of answers drops sharply for the last third. If you are asking people to review several colleagues, trim further.

Pick the right type for the job

• Behavioral prompts (“Describe a time…”) get you evidence a rating scale cannot. Use them for most questions.
• Rating scales (1–5 on a competency) make trends comparable across cycles. Use them for the same competencies every time.
• Start / stop / continue questions give the reviewee three clear things to act on and are quick to answer.
• Avoid yes/no questions and anything that asks for a personality verdict (“Is she a team player?”).

Questions for any individual contributor

These work for almost any non-managerial role and make a good base layer. Add the role-specific sets below on top, rather than replacing these.

• Ownership: Describe a time this person took ownership of something nobody had assigned to them. What happened?
• Reliability: How often did you have to follow up on something this person committed to? Give an example if you can.
• Communication: When this person disagrees with a plan, how do they raise it, and how do others react?
• Collaboration: What does this person do that makes working with them easier, or harder, for you specifically?
• Quality of work: Think of the last piece of their work you relied on. How much did you have to check or fix?
• Learning: What has this person got noticeably better at over the last six months?
• Priorities: When priorities changed, how did this person adapt, and how clearly did they tell you what that changed for them?
• Overall: What is the one thing you would ask this person to do more of, and the one thing to do less of?

Questions for software engineers

Engineering feedback goes wrong when it rates “technical skill” in the abstract. These questions ask about observable behavior in code review, estimates and incidents.

• Code quality: When you review this person’s code, what do you usually find: nothing, small style points, or design problems?
• Code review: How useful and how respectful are their review comments on your work?
• Estimation: How close have their estimates been to what actually happened, and how early do they flag a slip?
• Technical judgment: Give an example where this person chose a simpler solution over a clever one, or the reverse. Was it the right call?
• Incidents: How do they behave when production is broken: who do they pull in, and how clearly do they communicate status?
• Knowledge sharing: What have you learned from this person, through docs, reviews, pairing or talks?
• Scope: How well do they hold the line on scope, and how do they handle requests that grow mid-sprint?
• Testing: How confident are you shipping a change that depends on their work, and why?

Questions for people managers and team leads

Managers should be rated mostly by the people they manage, so make sure direct reports are among the reviewers. Keep these anonymous-by-aggregate if the team is small.

• Clarity: Do you know what is expected of you and how your progress will be measured? Where is it unclear?
• Feedback: How often does your manager give you feedback you can act on, and how soon after the event?
• Support: Describe a time they removed a blocker for you, or failed to.
• Development: What has your manager done in the last year to help you grow in the direction you want?
• Fairness: How consistent is your manager in how they treat different people on the team?
• Decisions: When they make a decision that affects you, do you understand the reasoning?
• Trust: How comfortable would you be telling your manager that you disagree, or that you made a mistake?
• Overall: What is the one thing you would ask your manager to start doing, and the one to stop?

Questions for sales and account roles

Revenue numbers already tell you the outcome. 360 feedback is useful for how the result was reached: handoffs, forecast honesty and how the person treats customers and colleagues.

• Forecast accuracy: How reliable is this person’s pipeline forecast, and how do they react when a deal slips?
• Customer relationships: How do customers talk about working with this person, in your experience?
• Handoffs: When this person hands a deal to onboarding or support, how complete and accurate is the context?
• Honesty: Have you ever had to correct something this person promised a customer? What was it?
• Collaboration: How do they work with product and marketing when a customer asks for something we do not have?
• Discipline: How well do they keep the CRM current so others can rely on it?
• Coaching: How much do they share what works with teammates, and how open are they to learning from others’ calls?

Questions for customer support and success

Ticket metrics miss tone and judgment. These questions ask the people who see the work, such as teammates, escalation owners and the engineers who take their bug reports.

• Empathy: When a customer is upset, how does this person respond, and how does the customer usually react?
• Accuracy: How often is the answer this person gives correct the first time?
• Escalation: When they escalate to you, is the report complete enough to act on without going back to the customer?
• Documentation: How well do they turn a repeated question into a help article or a saved reply others can use?
• Ownership: How do they handle a ticket that is not clearly theirs?
• Pressure: How do they behave during a high-volume day or an outage?
• Feedback loop: How well do they pass patterns they see in tickets to the product team?

Questions for product managers

Product work is mostly influence without authority, so the useful signal comes from engineers, designers and stakeholders rather than from the PM’s own manager.

• Prioritization: Do you understand why we are building what we are building? How well does this person explain trade-offs?
• Specs: How complete are their requirements when work starts, and how do they handle questions during the build?
• Stakeholders: How well do they set expectations with stakeholders, including when the answer is no?
• Data: Give an example of a decision this person made with evidence, and one made on instinct. How did each turn out?
• Collaboration: Do designers and engineers feel their input changes the outcome?
• Follow-through: After launch, how reliably does this person check whether the thing worked?

Who should answer them

Pick reviewers who have worked closely with the person in the review window: the manager, three to six peers, and direct reports where the person manages anyone. Include at least one person from a team the reviewee depends on or serves, since cross-team views are the ones a manager cannot supply.

Tell reviewers what the feedback will be used for before they write it. Feedback written for development reads very differently from feedback written for a pay decision, and people adjust their honesty accordingly.

What to do with the answers

Raw answers are not a review. Group them by theme, look for points that more than one reviewer made independently, and separate what is behavior from what is opinion. A single sharp comment is worth noting but not worth building a review on.

Then close the loop: turn the two or three strongest themes into specific points the person can act on, and put a date on when you will look again. The guide on writing a review from 360 feedback walks through this step by step.