The engineer was blindsided. Her annual review rated her "meets expectations," but she'd been told she was a top performer for the past eleven months. The gap between ongoing feedback and formal review destroyed her trust in her manager and the company.
This happens constantly. Performance reviews become disconnected rituals—managers fill out forms, engineers nod through meetings, and nothing changes. The ritual completes, but performance doesn't improve.
After helping over 50 engineering organizations rebuild their performance review systems at SmithSpektrum, I've found that effective reviews share specific characteristics. They're not about the form or the rating—they're about the conversation, the development, and the follow-through[^1].
Why Performance Reviews Fail
Performance reviews fail predictably.
Reviews surprise people. When the formal review contains feedback the engineer hasn't heard before, trust evaporates. Reviews should summarize ongoing conversations, not introduce new information.
Ratings dominate. The conversation becomes about justifying the rating rather than developing the engineer. People leave focused on the score, not on growth.
No follow-up happens. Development plans are written and filed. No one checks on progress. The review has no impact on actual performance.
One-size-fits-all. The same form applies to junior engineers and staff engineers, to high performers and struggling ones. Different situations require different conversations.
Recency bias rules. What happened last month overshadows the entire review period. Early-period work is forgotten.
The Continuous Feedback Foundation
Effective reviews are built on continuous feedback. The review meeting itself should contain zero surprises.
Monthly Feedback Cadence
| Touchpoint | Purpose | Format |
|---|---|---|
| Weekly 1:1 | Tactical feedback, blockers | Conversation |
| Monthly checkpoint | Progress against goals, early signals | Written summary |
| Quarterly review | Formal performance assessment | Documented meeting |
| Annual review | Career development, compensation | Formal process |
The quarterly cycle works better than annual for most engineering teams. A year is too long—feedback is stale, memories fade, and course correction comes too late.
Documentation That Enables Reviews
| What to Track | How Often | Why |
|---|---|---|
| Specific accomplishments | As they happen | Concrete evidence for reviews |
| Feedback given | When given | Pattern recognition |
| Development goals | Monthly | Progress tracking |
| 360 feedback | Quarterly | Multiple perspectives |
| Project outcomes | At completion | Impact measurement |
Managers who don't document throughout the cycle can't give meaningful reviews. They're forced to rely on memory, which means recency bias and forgotten contributions.
The Engineering Performance Framework
Evaluate engineers across dimensions that actually matter for engineering work.
Core Dimensions
| Dimension | What It Measures | Weight Guidance |
|---|---|---|
| Delivery | Does work ship? Quality? | 30-40% |
| Technical skill | Code quality, design, growth | 25-30% |
| Collaboration | Teamwork, communication | 15-20% |
| Leadership | Influence, mentoring, scope | 10-20% |
| Growth | Learning, stretch, development | 5-10% |
Weights should vary by level. Junior engineers are weighted toward delivery and growth. Senior engineers have higher collaboration and leadership weights. Staff+ engineers might be weighted 30%+ on leadership.
Level-Specific Expectations
| Dimension | Junior | Mid | Senior | Staff |
|---|---|---|---|---|
| Delivery | Completes defined tasks | Owns small projects | Owns large projects | Drives multi-team initiatives |
| Technical | Growing fundamentals | Solid in area | Deep expertise | Shapes technical direction |
| Collaboration | Responsive, coachable | Proactively helps | Multiplies team | Influences org |
| Leadership | Learning from others | Mentors new hires | Leads projects | Sets standards |
| Growth | Rapid improvement | Consistent growth | Developing expertise | Growing others |
Calibrate expectations to level. A senior engineer "meeting expectations" performs differently than a junior "meeting expectations."
The Rating Scale
Rating scales are tools for calibration, not ends in themselves.
The Five-Point Scale
| Rating | Label | Meaning | Typical Distribution |
|---|---|---|---|
| 5 | Exceptional | Transformative impact, well beyond level | 5% |
| 4 | Exceeds | Consistently above expectations for level | 20% |
| 3 | Meets | Solid performance at level, valued contributor | 60% |
| 2 | Needs Improvement | Gaps exist, development plan needed | 12% |
| 1 | Unacceptable | Significant issues, employment at risk | 3% |
Forced distributions (e.g., "only 10% can be 'exceeds'") are controversial but have merit: they force differentiation and prevent grade inflation. The downside: managers sometimes game them, rating good performers down to meet quotas.
My recommendation: use distribution guidelines, not hard caps. If a team is truly exceptional, let them be rated exceptional. But require justification when distributions vary significantly from expected.
Avoiding Rating Pitfalls
| Pitfall | What It Looks Like | Fix |
|---|---|---|
| Central tendency | Everyone gets "meets" | Require specific evidence for every rating |
| Recency bias | Last month dominates | Document throughout the period |
| Halo effect | One trait colors everything | Evaluate each dimension separately |
| Similar-to-me bias | Favorite styles rated higher | Use peer 360 feedback |
| Contrast effect | Comparing to wrong baseline | Compare to level expectations |
Structuring the Review Conversation
The meeting matters more than the document.
Pre-Meeting Preparation
Manager:
- Complete written assessment one week before meeting
- Review notes and documentation from full period
- Identify specific examples for each dimension
- Prepare development discussion
Engineer:
- Complete self-assessment
- List accomplishments from the period
- Identify growth areas
- Prepare career discussion points
Meeting Structure (60-90 minutes)
| Phase | Time | Purpose |
|---|---|---|
| Opening | 5 min | Set tone, establish agenda |
| Engineer's perspective | 15 min | Their self-assessment, accomplishments |
| Manager's assessment | 20 min | Feedback by dimension, specific examples |
| Alignment discussion | 15 min | Address gaps, questions |
| Development planning | 15 min | Goals, growth areas, support needed |
| Career discussion | 10 min | Longer-term trajectory |
| Next steps | 5 min | Commitments, timeline |
Start with the engineer's perspective. Let them talk first—it reduces defensiveness when they feel heard before receiving feedback.
Having Difficult Conversations
Not every review is positive. When addressing performance issues:
Be specific. "Your code quality needs improvement" is vague. "Three of your last five PRs had significant bugs caught in code review" is specific and addressable.
Focus on behavior, not character. "You've missed deadlines on three projects" addresses behavior. "You're unreliable" attacks character and triggers defensiveness.
Connect to impact. Explain why the issue matters. "When deadlines slip, other teams' work is delayed" shows consequence.
Co-create the path forward. Ask: "What would help you improve in this area?" The plan should be mutual, not imposed.
Document the conversation. For significant performance issues, written documentation protects both parties and ensures shared understanding.
Development Planning
Reviews should generate development plans, not just ratings.
Effective Development Goals
| Characteristic | Example |
|---|---|
| Specific | "Reduce PR review turnaround to <24 hours" not "improve code review" |
| Measurable | "Complete AWS certification by Q2" |
| Time-bound | "Lead one architecture discussion this quarter" |
| Stretch but achievable | Challenging but not impossible |
| Relevant to career | Aligns with growth trajectory |
Development Support
| Goal Type | Manager Support |
|---|---|
| Technical skill | Training budget, stretch projects, mentorship |
| Leadership | Opportunities to lead, visibility |
| Communication | Coaching, presentation opportunities |
| Career progression | Sponsorship, exposure, scope |
Goals without support are wishes. The development plan should include what the engineer will do and what the manager/company will provide.
Follow-Up Cadence
| Touchpoint | Timing | Purpose |
|---|---|---|
| Development check-in | Monthly | Progress on goals |
| Manager 1:1 | Weekly | Ongoing support |
| Quarterly review | Next quarter | Formal reassessment |
If development plans aren't discussed between reviews, they're not real. Build goal progress into the regular 1:1 agenda.
Calibration
Calibration ensures consistency across managers and teams.
The Calibration Meeting
| Stage | Purpose |
|---|---|
| Individual manager proposals | Each manager shares ratings and rationale |
| Cross-manager discussion | Identify inconsistencies, debate borderline cases |
| Level calibration | Ensure "senior" means the same across teams |
| Final decisions | Collective agreement on ratings |
Calibration surfaces biases. When one manager consistently rates higher than others, that pattern becomes visible and addressable.
What to Calibrate
| Dimension | Question |
|---|---|
| Ratings consistency | Does "exceeds" mean the same to everyone? |
| Level expectations | Is "senior" consistently defined? |
| Documentation quality | Are assessments equally specific? |
| Differentiation | Are managers distinguishing performance? |
Special Cases
High Performers
High performers need more than "great job, keep it up."
| Need | How to Address |
|---|---|
| Continued challenge | Stretch assignments, increased scope |
| Recognition | Visibility, promotion consideration |
| Retention risk | Compensation review, career discussion |
| Development | Even high performers have growth areas |
The biggest mistake: assuming high performers don't need development conversations. Everyone has gaps; high performers often have less tolerance for them going unaddressed.
Performance Improvement
When someone is below expectations:
| Stage | Actions |
|---|---|
| Initial conversation | Specific feedback, clear expectations, timeline |
| Performance Improvement Plan (PIP) | Written plan, weekly check-ins, 30-60 day timeline |
| Regular monitoring | Documented progress or lack thereof |
| Decision point | Continue, extend, or exit |
PIPs should be genuine opportunities for improvement, not just documentation for termination. Some engineers genuinely turn around with clear expectations and support.
The engineer who was blindsided by her review? Her company rebuilt their feedback system. Monthly checkpoints, documented feedback, quarterly reviews. When her next review came, she knew exactly what to expect—because she'd heard it all before, throughout the year.
The review conversation should summarize what you've already discussed, not reveal it.
References
[^1]: SmithSpektrum performance management advisory, 50+ companies, 2020-2026. [^2]: Lattice, "The State of People Strategy," 2025. [^3]: CultureAmp, "Performance Management Benchmarks," 2025. [^4]: Radford (Aon), "Engineering Compensation and Practices Survey," 2025.
Need help redesigning your engineering performance review process? Contact SmithSpektrum for framework design and implementation support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum