The problem with most performance review phrase lists is that they describe no one in particular. "Demonstrates strong technical skills." "Communicates effectively." These could appear in any engineer's review — which means they say nothing useful about this engineer's quarter.
What follows is different. Every phrase below is specific enough that it only fits someone who actually did the thing it describes. Swap in the real project names and numbers, and you have feedback that's credible, actionable, and actually useful for the person receiving it.
Organized by the four dimensions that matter most in an engineering review: technical skills, leadership, collaboration, and growth areas.
Technical Skills
Technical feedback is where engineering reviews either earn trust or lose it. Vague praise ("great engineer") lands with the same weight as no feedback at all. The phrases below name what the engineer actually did — and why it mattered.
Strong Performance
- "Refactored the authentication service in Q1, reducing average latency from 420ms to 85ms and eliminating the top recurring alert in our on-call rotation — no regressions in six weeks since deploy."
- "Designed the new data ingestion pipeline with horizontal scaling from the start; when ingest volume doubled unexpectedly in March, no changes were required and p99 latency held under 200ms."
- "Caught a race condition in code review that would have caused silent data corruption in the billing reconciliation job. The fix was non-trivial and required rethinking the locking strategy entirely."
- "Delivered the search reindex with zero downtime despite a 3x increase in index size. Wrote a detailed migration runbook that the team will use as a reference for future large-scale data migrations."
- "PR review quality is consistently high — comments are explanatory, not prescriptive, and routinely catch both bugs and design issues that would have required follow-up PRs to fix."
Needs Improvement
- "Three of the five services shipped in Q1 required follow-up patches within two weeks for edge cases that weren't covered in testing. The pattern suggests the unit tests are passing the happy path but not being written for failure modes — this is the specific area to focus on."
- "The initial architecture for the notifications service put business logic in the API handler layer, which made it untestable and hard to extend. After two rounds of review feedback it was restructured, but this pattern has recurred across other PRs this quarter."
- "Debugging sessions with the team frequently surface that the issue was already visible in the logs. Building the habit of log-first investigation before pinging teammates would speed up resolution time and reduce context-switching for others."
- "Pull requests are often submitted before the feature is fully working, which creates review overhead and back-and-forth. Self-testing to a 'demo-ready' standard before opening a PR would change the review dynamic significantly."
Leadership
Leadership in engineering doesn't always come with a title. You're evaluating how this person shapes the work around them — do they raise the quality of the team, or just their own output?
Strong Performance
- "Ran the incident retrospective for the March database outage, identified three contributing factors that weren't in the initial post-mortem, and shepherded all follow-up action items to completion within three weeks. The team handled the next incident noticeably faster."
- "Pushed back on the Q1 sprint scope in week two when it became clear that the data model underlying the feature was wrong. The conversation was uncomfortable, but the redesign saved an estimated two weeks of rework and the final implementation is extensible."
- "Onboarded two new engineers this quarter. Both are committing to production in week three — ahead of the team's historical median of six weeks. The onboarding doc created for this process is now the team standard."
- "Proposed and drove adoption of the new code review guidelines. Two months in, average time-to-merge has dropped from 3.2 days to 1.4 days without an increase in post-merge defects."
Needs Improvement
- "When the sprint goal was at risk in February, the team didn't know until the Friday standup. Earlier escalation — even a quick Slack message when the blocker first appeared — would have given the team time to adjust. This is the single highest-leverage change for Q2."
- "Technical decisions are made individually and then presented as done. Bringing the key tradeoffs to the team before deciding — even asynchronously — would build buy-in and surface information that sometimes only comes out after the fact."
- "Junior engineers on the team rarely ask for help in public channels, but in 1:1s they mention being stuck. More active check-ins — a quick 'how's the infra work going?' in Slack — would surface blockers earlier and signal that asking is normal."
Collaboration
Engineering doesn't happen in isolation. How this person works across teams, communicates tradeoffs to non-technical stakeholders, and shows up in shared processes matters as much as what they build.
Strong Performance
- "Worked directly with the product manager and designer on the permissions overhaul to surface technical constraints early — before designs were finalized. This avoided a complete design revision that would have happened in sprint three had these constraints come up later."
- "During the Q1 planning cycle, wrote a two-page technical summary of the proposed auth migration for the executive team. Non-technical stakeholders consistently understood the tradeoffs and the decision timeline as a result."
- "When the data team needed access to events that our service wasn't emitting, the response was a proposed schema, a timeline, and a handoff plan — not a ticket sitting in the backlog. That kind of proactive coordination shortened the project timeline by two weeks."
- "Keeps the team's external documentation current. Other teams reference our API docs and runbooks regularly, and the compliments we receive on them are directly attributable to the maintenance investment made this quarter."
Needs Improvement
- "Three times this quarter, product discovered that a technical decision affected their roadmap after it was already implemented. Earlier visibility — even a 'heads up, we're going to do X this week' — would prevent surprises that create trust issues downstream."
- "In cross-team planning meetings, technical explanations frequently use terminology that the product and design participants aren't following. The outcome is either delayed decisions or decisions made without real understanding. Building the habit of one-sentence plain-language summaries before going deeper would fix this."
- "PR feedback is accurate but sometimes delivered in a way that shuts down discussion rather than opening it. Phrasing suggestions as questions ('have you considered X?') rather than directives lands better and gets to the same place."
Growth Areas
Growth-area phrases are the hardest to write. The goal is to be honest about a real development opportunity without making it sound like a PIP. The key: tie it to specific evidence, state the impact clearly, and point toward what improvement looks like.
"When requirements are unclear, the default response is to pause work and wait for full clarity. In Q1 this added up to about a week of blocked time across three different projects. Building comfort with making a reversible decision and moving forward — then adjusting when more information arrives — is the most impactful thing to work on in Q2."
"The calendar client integration shipped two weeks late because the scope expanded mid-sprint without being surfaced as a risk. The work was good — but the timeline miss affected two other teams who were waiting on it. When scope starts expanding, that's the moment to bring it to the team, not after."
"Technical design docs this quarter required multiple rounds of back-and-forth to reach shared understanding. The issues weren't the ideas — they were structure and clarity. Investing in doc-writing (starting with a clear problem statement before proposing solutions) would make the review cycle faster and decisions more durable."
"Solutions are consistently well-executed at the feature level but don't yet account for how changes propagate to other systems. The Q1 caching change that caused unexpected behavior in the reporting pipeline is the clearest example. Before implementing, asking 'what else reads or writes this data?' would catch these interactions earlier."
Common Mistakes Engineering Managers Make in Reviews
One More Thing
The phrases above are starting points. The real work is in swapping the placeholders for actual project names, real metrics, and the specific behaviors you observed. That work requires notes — which means the engineers who have been keeping running 1:1 docs and project journals all quarter are the ones whose reviews get written fastest and land hardest.
If you want to see what a fully written engineering performance review looks like before you start yours, the Kudo sample review shows the full structure, including how specific phrases get woven into a cohesive narrative rather than a list of bullet points.
Q1 review season is here. April 2026 is the deadline for most teams doing their first cycle of the year. These phrases are ready to use — the specifics are yours to fill in.
Let Kudo write the first draft.
Kudo interviews each engineer about their Q1 work, then drafts a full performance review with specific, cited feedback — organized exactly like the examples above. Free tier: 2 reviews per cycle, forever.
Try Kudo Free →