What is a performance review checklist?
A performance review checklist is a structured workflow that engineering leaders follow before, during, and after performance conversations. It ensures reviews are evidence-based rather than recency-biased, that feedback is specific and actionable, and that the conversation builds trust rather than anxiety. This checklist covers the full cycle: gathering 360° feedback, running the review conversation, separating development feedback from compensation decisions, and following up with written summaries and development goals.
Key Takeaways
- Gather 360° feedback from peers and stakeholders before every review
- Start the conversation with recognition — specific accomplishments, not generic praise
- Co-create growth goals with the engineer rather than dictating them
- Run development feedback on a separate cadence from compensation conversations — defensiveness kills receptivity
- Always send a written summary and schedule a follow-up within 4–6 weeks
Preparation
Gather 360° feedback from peers and stakeholders
Reach out to 3–5 people who work closely with the engineer. Ask specific questions about collaboration, technical contributions, and communication.
Review goals and performance data from the past cycle
Pull data from your project management tools, code review history, and previous 1:1 notes. Look at what was committed versus what was delivered.
Analyze feedback from 1:1s and sprint reviews
Review your running notes from 1:1s. Identify recurring themes — both positive patterns and areas that kept coming up.
Identify growth moments and areas for improvement
Note specific examples where the engineer stretched beyond their comfort zone or where they struggled. Concrete examples make feedback credible.
Skip the review season panic
HackerPulse collects 50+ data points per engineer throughout the year. When calibration comes around, you have actual evidence instead of trying to remember what happened six months ago.
Try it freeDuring the Review
Start with recognition of accomplishments
Lead with what went well. Be specific — name the project, the impact, and why it mattered. Generic "great job" undermines trust.
Discuss feedback constructively and clearly
Use the SBI model (Situation, Behavior, Impact) to deliver constructive feedback. Avoid vague statements — give the engineer something they can act on.
Co-create growth goals with the team member
Don't dictate goals. Ask the engineer where they want to grow and find alignment between their ambitions and team needs.
Ensure psychological safety throughout the conversation
Make it a dialogue, not a monologue. Ask how your feedback lands. Be open to their perspective on their own performance.
Post-Review
Send a written summary of the conversation
Within 24 hours, send a document summarizing key feedback, agreed goals, and next steps. This creates accountability on both sides.
Schedule a follow-up to revisit goals in 4–6 weeks
Don't let goals gather dust. A follow-up ensures progress and shows the engineer you're invested in their growth.
Track development areas in future 1:1s
Integrate review goals into your 1:1 agenda. Check in regularly on progress and adjust as needed.
Celebrate progress and learning, not just outcomes
Recognize effort and growth, not just results. Engineers who feel their development is valued stay longer and contribute more.
Separate development feedback from compensation
The moment a feedback conversation also decides someone's pay, the conversation changes. People go from listening to defending. Even feedback they'd normally welcome lands as a justification for a rating they're about to be handed. The fix is to decouple the two cadences. Run development conversations regularly through the year, in 1:1s and mid-cycle check-ins, so growth feedback is normal, expected, and not load-bearing. Then handle compensation as a separate, shorter conversation focused on the decision itself: here's the rating, here's how it maps to your band, here's the reasoning behind it. When compensation does come up, transparency is the antidote to resentment. When engineers understand how performance was measured and why their rating landed where it did, they push back on the assessment if they disagree. That's the conversation you want. The alternative is quiet disengagement.