A strong performance review is specific, behavioral, evidence-based, and balanced. It references observable actions and their impact rather than personality traits. It draws from the full review period rather than recent weeks. And it provides enough detail that the employee knows exactly what to continue doing, what to change, and what support they’ll receive.
Most performance reviews fail this standard — not because managers lack writing ability, but because they lack documented evidence to draw from. A manager writing from memory produces vague, generic language. A manager writing from organized, time-distributed feedback produces specific, actionable reviews.
This guide provides concrete examples of performance review language across situations — manager evaluations, peer feedback, self-assessments, and goal summaries — with weak and strong versions side by side. Each example illustrates what makes the difference between a review that changes behavior and one that gets filed and forgotten.
Weak: > “Emily consistently exceeds expectations. She’s a top performer who always delivers quality work. She’s a natural leader and a great asset to the team. I’d recommend her for promotion.”
Why this fails: No specific examples. “Top performer,” “natural leader,” and “great asset” are generic praise that could describe anyone. There’s nothing the employee can point to and say “this is what I should keep doing.” And a promotion recommendation without documented evidence is hard to defend in a calibration conversation.
Strong: > “Emily led the migration of our payment processing system from Stripe v2 to v3 between March and June, completing the project two weeks ahead of schedule while maintaining 99.97% uptime during the transition. She identified a potential data integrity issue during the testing phase that the vendor’s own migration guide didn’t address, and her solution was later adopted by three other teams in the organization. > > Beyond the technical execution, Emily mentored two junior engineers through their first production deployment during this project. Both reported in their self-assessments that Emily’s structured approach to code reviews and pair programming significantly accelerated their learning. The engineering lead for Platform noted that Emily’s documentation of the migration process has become the internal reference guide for future vendor migrations. > > Emily’s development area this period has been stakeholder communication. Her technical updates to the product team were thorough but occasionally too detailed for a non-technical audience. We’ve discussed adapting the level of detail to the audience, and her Q4 updates to leadership showed meaningful improvement — the VP of Product specifically commented that her status reports were clearer and more actionable.”
Why this works: Specific project with dates and measurable outcomes. References multiple sources (self-assessments from direct reports, feedback from engineering lead and VP). Covers the full review period (March through Q4). Development area is specific and shows progress, not just a problem.
Weak: > “Marcus is a solid performer who meets expectations consistently. He completes his work on time and contributes to team discussions. No significant issues this period.”
Why this fails: “Solid performer” and “meets expectations” without examples tells the employee nothing. “No significant issues” frames adequate performance as the absence of problems rather than the presence of contributions. This review is so generic it would take less time to not write it.
Strong: > “Marcus managed the customer onboarding pipeline for the Mid-Market segment throughout the review period, maintaining a 94% on-time completion rate against a 90% target. His onboarding playbook, developed in Q1 and refined in Q3, has been adopted by the Enterprise segment as a starting template — a signal that his process thinking is valued beyond his immediate scope. > > Marcus’s client communication is consistently professional and responsive. Three client feedback surveys this period specifically mentioned his responsiveness and clarity during the onboarding process. He has also been reliable in cross-functional coordination with the Product and Engineering teams — the Technical Account Manager noted that Marcus flags integration issues earlier than most onboarding leads, which reduces escalations. > > Area for growth: Marcus has expressed interest in moving into a team lead role. The gap between his current individual contribution and that role is primarily in proactive project ownership — taking initiative on process improvements without being asked. His onboarding playbook is a good example of what this looks like; the goal for next period is to apply that same proactive approach to two additional process areas he identifies on his own.”
Why this works: Specific metrics, specific examples, specific feedback from clients and colleagues. The development area connects to the employee’s stated career goals and includes a concrete target. The language is respectful and forward-looking — “area for growth” is constructive, not dismissive.
Weak: > “Lisa has been underperforming this quarter. She needs to step up her work and show more initiative. If things don’t improve, we may need to consider a performance improvement plan.”
Why this fails: No specific examples of underperformance. “Step up” and “show more initiative” are not actionable. Threatening a PIP without documented specifics is both legally risky and managerially ineffective. The employee leaves this review knowing they’re in trouble but not knowing what to change.
Strong: > “Lisa missed delivery commitments on four of six client projects this period. Specifically: the Acme Co. implementation was delivered 10 business days late (original deadline: April 15, delivered: April 29), the TechStart integration was delivered 7 business days late, and the GlobalFin and SoftwareCo projects are both currently behind schedule by approximately two weeks. In each case, the delay was communicated to stakeholders after the deadline had passed rather than flagged in advance. > > When Lisa’s deliverables arrive, the quality is consistently strong. The Acme Co. implementation, despite the delay, received positive feedback from the client — they noted the thoroughness of the documentation and the clean data migration. This suggests the issue is scope estimation and timeline management rather than capability. > > I’ve observed that Lisa tends to accept project timelines without pushing back when she has concerns about feasibility. In our 1-on-1 on March 8, she mentioned feeling that the Acme timeline was ‘aggressive’ but didn’t raise this during project planning. Building the habit of flagging risks early — before they become deadline misses — is the critical skill gap. > > Development plan for next period: (1) Lisa will flag any project at risk of delay at least 5 business days before the deadline, (2) we will do scope estimation together for the next three projects before committing to timelines, and (3) Lisa will track all project milestones in the shared project board with weekly status updates. We’ll assess progress at our biweekly 1-on-1s, and I expect to see measurable improvement in on-time delivery by the end of next quarter.”
Why this works: Specific projects, specific dates, specific patterns. Acknowledges what Lisa does well (quality). Identifies the root cause (scope estimation, not capability). Development plan has measurable actions and clear timelines. This review would support a PIP if improvement doesn’t happen — but it also gives Lisa a genuine path to improvement.
Weak: > “David is great to work with. He’s always helpful and friendly.”
Strong: > “During the Q3 product launch, David volunteered to take on the API documentation updates when our technical writer was on leave. He completed the documentation for all 12 endpoints in four days, and the docs were accurate enough that the partner integration team was able to self-serve without additional support calls. This saved the team approximately 15 hours of integration support time. David also proactively set up a shared FAQ document based on questions he anticipated from the partner team, which has been referenced 40+ times since launch.”
Weak: > “Sarah could communicate better. Sometimes I don’t know what’s going on with her projects.”
Strong: > “On the Atlas project in Q2, there were three instances where I needed status updates from Sarah’s workstream to unblock my own tasks, and in each case I had to ask directly rather than finding the information in our project channel. For example, on May 12, I waited two days for a status update on the data export before reaching out — and learned the export had already been completed but wasn’t communicated. Having a brief end-of-day update in the project channel when key milestones are reached would help the rest of the team plan around dependencies.”
Why the strong version works: Describes specific instances, not character traits. Offers a concrete, low-cost solution. Maintains respect while being honest about the impact.
Weak: > “I had a good year. I completed all my projects on time and helped the team when needed. I’d like to take on more responsibility next year.”
Strong: > “My three most significant contributions this period were: > > 1. Customer Health Score System (Jan–Mar): I designed and implemented the automated customer health scoring model that now covers our top 200 accounts. The model surfaces at-risk accounts 3–4 weeks earlier than our previous manual review process. Since launch, the CS team has intervened on 12 accounts that the old process wouldn’t have flagged until renewal conversations. > > 2. Onboarding Automation (Apr–Jun): I built the automated onboarding email sequence that reduced manual CS touchpoints during the first 30 days from 8 to 3 while maintaining the same customer satisfaction scores (4.6/5.0 pre-automation vs. 4.5/5.0 post-automation). > > 3. Mentoring New Team Members (ongoing): I onboarded and mentored two new Customer Success Managers who joined in Q2. Both completed their ramp period within the expected 60-day window, and Elena’s Q3 retention rate for her portfolio was 96% — above the team average of 93%. > > Biggest challenge: I struggled with prioritization in Q3 when the product team accelerated the dashboard redesign timeline. I tried to maintain my existing workload while supporting the redesign feedback process, which resulted in my monthly account reviews slipping by a week in August and September. In retrospect, I should have flagged the bandwidth conflict earlier and worked with my manager to deprioritize something rather than trying to absorb the additional work. > > Growth focus: I want to develop my skills in data analysis and reporting. I can build dashboards, but I want to get better at extracting strategic insights from the data and presenting those insights to leadership in a way that drives decisions.”
Why this works: Specific accomplishments with measurable outcomes. Honest assessment of a challenge — not defensive, not self-flagellating. The growth area is specific enough to build a development plan around. A manager reading this self-assessment has significantly more to work with than one reading “I had a good year.”
Goal: Improve customer satisfaction Status: On track Notes: Customers seem happy overall. No major complaints this quarter.
Goal: Increase average CSAT score from 4.2 to 4.5 by end of Q4 Status: Achieved — current CSAT at 4.6 as of December review Key actions taken: - Implemented 48-hour response time SLA for all support tickets (previously no formal SLA). Average response time dropped from 72 hours to 31 hours. - Created proactive check-in cadence for top 50 accounts — monthly for strategic accounts, quarterly for growth accounts. This surfaced three product issues that were resolved before they generated support tickets. - Trained the support team on the new escalation framework in August. Post-training, escalation resolution time improved by 40% (from avg 5 days to avg 3 days).
What I’d do differently: I focused heavily on response time early in the period, which was the right call, but I waited too long to address the proactive check-in cadence for non-strategic accounts. Starting that in Q2 instead of Q3 would likely have moved the CSAT number faster.
Understanding the spectrum of review language helps managers calibrate their evaluations and helps employees interpret the feedback they receive.
Neutral language describes competent, reliable performance that meets the requirements of the role without significant standout moments or concerns:
Neutral language is appropriate for the majority of competency areas for the majority of employees. Not every dimension of performance needs to be exceptional.
Strong language describes performance that demonstrably goes beyond role requirements, creates outsized impact, or shows growth that elevates the person’s contribution:
Concerning language describes performance gaps that need to be addressed, framed around specific behaviors and their impact rather than character judgments:
Critical note: Concerning language should always be paired with specific examples and a clear development plan. Language that identifies a problem without a path forward is not a review — it’s a complaint.
The examples above share a common characteristic: they’re built from evidence, not from memory. The manager writing about Emily’s payment processing migration had access to project timelines, peer feedback, and documented stakeholder comments. The manager writing about Lisa’s delivery issues had access to specific dates and a record of 1-on-1 conversations.
This is the fundamental insight about review quality: the writing isn’t the hard part. The evidence is.
When organizations invest in collecting feedback throughout the year — through continuous feedback systems that capture observations from managers, peers, and the employees themselves — the review writing process transforms from a memory exercise into a synthesis exercise. The manager’s job shifts from “recall everything this person did” to “organize and interpret the evidence that already exists.”
Teams using WorkStory see this shift in practice: feedback captured automatically from Slack and Teams throughout the year is organized by employee and competency. When review time arrives, the manager reviews documented evidence from the full period and refines an AI-generated draft with their own judgment and context. Reviews that previously took 3–5 hours take about 30 minutes — and the quality improves because the evaluation draws from a complete evidence base rather than recent memory.
How long should a performance review be?
There’s no universal standard, but effective reviews are typically 400–800 words for the manager evaluation section. Shorter reviews tend to lack the specificity needed for actionable feedback. Longer reviews risk burying key messages in too much detail. The goal is enough specificity to be useful, not comprehensive documentation of every observation.
Should reviews include numerical ratings alongside written feedback?
Both serve different purposes. Written feedback drives individual development — it tells the employee what specifically to do more of and less of. Numerical ratings enable organizational decision-making — calibration across teams, compensation modeling, and talent planning. The most effective reviews include both, with the written component doing the heavy lifting for the employee and the rating serving the organizational function.
How do you write a review for someone you just started managing?
Lean heavily on other sources: peer feedback, the previous manager’s most recent evaluation, self-assessment, and documented project outcomes. Be transparent about the limitation: “I’ve been managing Alex for the last three months, so this review draws significantly from peer feedback and documented project outcomes for the first half of the period.” Honesty about the limitation is more credible than pretending to have a full-year perspective.
What if the employee disagrees with the review?
Document the disagreement and the reasons behind it. If the review is evidence-based, share the specific feedback and observations that informed the evaluation. The conversation should focus on “here’s what the evidence shows” rather than “here’s what I think.” When the evidence is documented — rather than existing only in the manager’s memory — disagreements become a discussion about interpretation rather than a conflict about facts.
How should reviews differ for high performers vs. average performers?
High performer reviews should emphasize what specifically makes their work exceptional and articulate the path to the next level. Average performer reviews should identify the one or two changes that would most move the needle, rather than listing every possible improvement. Both should be equally specific — a common mistake is writing detailed reviews for underperformers but generic praise for strong performers, which leaves top talent without actionable development guidance.
Is there a formula for constructive feedback?
The most reliable structure is: Specific observation → Impact → Forward-looking expectation. Example: “Your project updates in Q3 were submitted after stakeholders had already made decisions based on outdated information [observation]. This caused two instances of rework on the integration timeline [impact]. Going forward, project updates should be shared by 5pm on Fridays, before the Monday planning meeting [expectation].” This structure keeps feedback behavioral, connected to outcomes, and actionable. For more on how feedback inputs affect review quality, see the guide on performance review feedback.
When reviews are built from a year of documented feedback instead of memory, they sound like the strong examples above — not the weak ones. See how WorkStory works →
