The Engineering Performance Review That Engineers Find Useful
An engineering performance review that engineers find useful is one where the feedback is specific, connected to observable work, and actionable within the next review cycle. The review that engineers dread is the one where feedback is vague, unsurprising (because no feedback was given during the year), or disconnected from the criteria for advancement. The difference is in the process that produces the review, not in the review meeting itself.
Written by Yashveer Singh, founder of Yashveer Labs.
What you actually need to know
- The performance review is the documentation of what should have been said throughout the year. If the review contains surprises, the feedback process failed.
- Engineer self-assessment against the career ladder is the most efficient input to the review. It surfaces gaps in the engineer's understanding of the criteria.
- Specific, observable behavioral feedback is more useful than ratings. "Met expectations" tells the engineer nothing.
- The outcome of every performance review should be three to five specific development priorities for the next six months.
- Peer review adds signal but should not override the manager's direct observation of the engineer's work.
| Review Component | What Makes It Useful | Common Failure |
|---|---|---|
| Self-assessment | Against specific career ladder criteria | General reflection without criteria |
| Manager assessment | Specific behavioral examples | Ratings without evidence |
| Peer review | Specific observations from working together | Generic "great to work with" |
| Development priorities | 3-5 specific, time-bound actions | Vague "continue to grow in X" |
| Promotion discussion | Specific criteria mapping | "Not quite ready yet" |
The core argument
The engineering performance review that engineers dread has a consistent profile: it happens once per year, contains feedback the engineer has not heard before, is delivered as a rating on abstract dimensions, and produces no specific development guidance. The engineer leaves the meeting knowing their rating and not knowing what to do differently. The manager leaves having discharged the HR obligation.
The review that engineers find useful has a different structure. The engineer and manager have been discussing performance throughout the year, so the formal review is not introducing new information. The review is anchored to the career ladder criteria, so the assessment is specific and evaluable. The manager provides behavioral feedback with specific examples. The review concludes with a development plan that has specific priorities and a timeline.
The process that produces the useful review starts in the 1-on-1s throughout the year. A manager who is giving career development feedback monthly has a 12-month record of observations to draw on in the formal review. The formal review becomes a synthesis of the year's feedback rather than an annual event where feedback is delivered for the first time.
This is the most important structural change in performance reviews: make feedback continuous and make the formal review a documentation and calibration exercise, not the primary delivery vehicle for annual feedback.
Designing the self-assessment
The self-assessment is the engineer's evaluation of their own performance. When structured well, it is the most efficient input to the review process: it surfaces where the engineer and manager agree (which does not require much discussion) and where they disagree (which is the most important part of the review conversation).
A self-assessment anchored to the career ladder criteria is more useful than an open-ended reflection. Ask the engineer to evaluate themselves against each criterion for their current level: do they meet this criterion, do they exceed it, or do they not yet meet it? Provide a specific example for each criterion.
The manager then does the same exercise independently. When both assessments are complete, the review conversation focuses on the criteria where the assessments differ. An engineer who rates themselves as exceeding a criterion and the manager rates as meeting is a productive conversation: what evidence does the engineer have that they exceed it, and what evidence does the manager have that they meet it? This conversation produces shared understanding and often reveals gaps in the engineer's understanding of what "exceeding" looks like at the next level.
The self-assessment should not be a test. Engineers who fear that a candid self-assessment will be used against them will be strategically positive. A culture where honest self-assessment is rewarded because it produces useful conversations is required for the self-assessment to work.
Writing specific behavioral feedback
Behavioral feedback is specific, observable, and connected to impact. Rating feedback is a number on a scale that provides no information about what the engineer should do differently.
Good behavioral feedback: "In the Q3 authentication refactor, you made the architecture decision to use JWTs without documenting the security trade-offs. When the security review surfaced concerns two weeks later, the team had to revisit the decision with less information than you had when you made it. For the next quarter, I want to see you document the security trade-offs for any authentication-related decisions before finalizing them."
Bad rating feedback: "Communication: 3 out of 5. Technical Execution: 4 out of 5."
The good feedback tells the engineer what specifically happened, why it was a problem, and what to do differently. The rating tells them where they rank on abstract dimensions without actionable guidance.
Writing specific behavioral feedback requires observing specific work. A manager who is not close enough to the work to describe specific examples cannot provide useful feedback. If the manager's feedback is generic, the cause is typically insufficient direct observation of the engineer's work. The solution is more observation, not better performance review templates.
The development plan
Every performance review should end with a development plan: the three to five specific things the engineer is working on improving in the next review cycle. These should be specific, measurable, and time-bound.
Good development priority: "Write the architecture design document for the new notification system before starting implementation. Use the feedback from your last design review as a checklist: include failure mode analysis, data model justification, and API contract specification."
Bad development priority: "Continue to develop your technical communication skills."
The good priority tells the engineer what to do, when to do it, and how success will be measured. The bad priority is unmeasurable and unactionable.
The development plan is reviewed in monthly 1-on-1s. Progress is tracked throughout the cycle, not evaluated only at the next review. An engineer who is not making progress on a development priority needs feedback and potentially support, not a year-end observation that the priority was not addressed.
Common mistakes engineering leaders make with performance reviews
- Delivering feedback in the review that was not given during the year. This is a management failure, not a review process failure. The fix is monthly feedback, not a better review template.
- Using vague language to avoid difficult conversations. "Room for growth" and "not quite at the next level" are not feedback. Specific behavioral observations with specific development guidance are feedback.
- Separating the review from the career ladder. Reviews that are not anchored to the ladder criteria cannot produce promotion decisions that engineers trust.
- Not doing peer review because the process is overhead. Peer review surfaces information the manager cannot observe directly. Done efficiently (five to seven specific questions, not open-ended essays), it adds significant signal.
- Not following up on development priorities in 1-on-1s. A development plan that is created in December and reviewed the following June does not drive development. Monthly check-ins on progress do.
Where to start: a 3-step review improvement
Step 1: Anchor the review to the career ladder. Build the self-assessment and manager assessment templates around the specific criteria for each level. If the ladder is not specific enough for this, fix the ladder first.
Step 2: Introduce monthly career development check-ins in 1-on-1s. Spend 15 minutes of each monthly 1-on-1 on career development: where is the engineer relative to their development priorities, what is their next promotion goal, and what are they working on to get there?
Step 3: Require specific behavioral examples for every assessment dimension. Remove ratings and require behavioral examples in the review template. An assessment dimension with no example is a flag that the manager does not have sufficient direct observation of the engineer's work.
Reviews That Actually Drive Growth
Yashveer Singh. Founder of Yashveer Labs. The performance review is a contract between the engineer and the team: here is what good performance looks like, here is where you are against that standard, here is what you are working on. When it is specific enough to be a real contract, engineers can use it to navigate their development. When it is vague, it is noise. The specificity is the investment that makes the process worth running.
Related reading
Frequently asked
My approach to this kind of work
I approach this kind of work the way I would want someone to approach a system I depended on. With care, with rigor, with a sense that the next person who touches it should be able to understand it without my help. Yashveer Singh, founder of Yashveer Labs. That is the standard. If it is the standard you are looking for, I am the engineer to hire.
Posts that line up with this one.
- Startup Technical Strategy
The Engineering All Hands That Engineers Look Forward To
What makes an engineering all-hands worth attending instead of a meeting engineers endure, and how to structure one that actually builds alignment.
- Startup Technical Strategy
The Engineering Career Ladder That Engineers Trust
What makes an engineering career ladder credible to engineers instead of a performance review document that explains why everyone is underpromoted.
- Startup Technical Strategy
The Engineering Culture Document That Engineers Actually Read
What engineering culture documents actually need to say to be useful, not decorative -- and how to write one that engineers trust.
- Startup Technical Strategy
The Engineering Org Chart at 5, 25, and 100 Engineers
How engineering team structure evolves across the three most critical inflection points as startups scale -- and the mistakes that make each transition harder.