How to Conduct Fair Team Performance Reviews: A Manager’s Playbook
A manager explains the performance review process, why results are rarely changed after publication, how adjustments are made with the CTO, and offers concrete advice on asking the right questions, setting specific goals, and maintaining continuous feedback throughout the year.
Every six months I evaluate my team members and also participate in performance calibration with the CTO, so I’ll share the process from a manager’s perspective.
Conclusion: accept the result, but ask for the reasons.
When the review is released, the outcome is essentially final; successful appeals are extremely rare.
The workflow is:
First, I draft the individual performance scores.
After drafting, I do not publish immediately; I sync with the CTO.
The CTO often adjusts scores based on the overall IT department’s situation, balancing across development, design, implementation, BI, and other teams.
Adjustment reasons typically include:
Once the final scores are set, we meet each team member individually.
If you receive a C, the leader should explain why during the performance interview; otherwise the employee may go to HR or higher management, which benefits no one.
Why can’t the result be changed later?
At that stage, changes are highly unlikely. The valuable effort is to understand the underlying reasons.
Do not ask, “Why did I get a C?” because the leader often cannot give a satisfying answer.
Better questions are:
Which specific actions led to this rating?
Avoid vague answers like “overall performance was average.”
Ask the leader to cite concrete examples, such as project delays, production incidents, communication issues, delivery capability, or complaints from other departments.
Knowing the exact problems tells you how to improve.
To move from a C to a B or A, you need a clear target from the leader, e.g., taking ownership of a core project, handling more business, mentoring newcomers, or improving delivery speed.
Only specific goals give direction for the next period.
Example: In 2025 I told a front‑end developer that if he could handle Java back‑end tasks in 2026, I would award him an A, because that exceeds his role expectations and boosts the team’s capability.
Another tip: don’t wait until the performance meeting to learn the leader’s evaluation. Communicate regularly, debrief after project milestones, and verify that your goals remain aligned.
Effective performance management is not a year‑end discussion but continuous calibration throughout the year.
Ultimately, assess two things:
Do you accept the reasons the leader provides?
If you follow those reasons, will the next review likely improve?
If both answers are yes, work on the feedback and aim for a better rating. If the reasons are unclear or effort won’t change the outcome, consider building strong résumé highlights in the current company and start preparing for the next opportunity.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
samdeepthink
Knowledge Planet: Old Dock's Tech Chronicles Zhihu: SamDeepThinking A technical manager who still codes heavily on the front line. From junior developer to tech lead, then tech manager, now leading the whole front‑ and back‑end development team—leveling up along the way. I have some insights on programming, career development, and tech management.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
