Someone who overrates their work should hear a comparison between their claim and inspectable results, not a humiliating verdict. Bring review history, incident outcomes, delivery evidence, and relevant peer input. Ask how they reached their assessment, identify the standard you both will use, and choose a near term piece of work where good performance can be observed.
Which artifacts should you prepare?
Select evidence tied to the work they rate highly. If they call a service redesign exceptional, bring the accepted design, review changes, escaped defects, incident record, and delivery result. Include strengths as well as misses. The aim is not to assemble every mistake. It is to compare the engineer's claim with the same artifacts that informed your judgment.
Use peer evidence carefully. “Everyone thinks your work is mediocre” is cruel and impossible to answer. A stronger example says that three reviewers independently identified missing retry behavior, and the service later failed under the exact condition. Protect private comments where required, but do not hide observable engineering facts behind anonymous opinion.
How do you start without humiliating them?
Open with the gap: “You assessed the billing migration as exceeding the senior standard. My assessment is that it met part of the standard and missed important reliability work. I want to compare the evidence and agree what good looks like on the next change.” This is direct, but it does not turn a rating difference into a spectacle.
Hold the conversation privately and allow time. Do not surprise the engineer during calibration or correct their self assessment in front of peers. Confidence can be sincere. They may use a different standard, lack comparison points, or emphasize complexity over outcome. Understanding their reasoning helps you teach the actual bar.
How should you compare claim and result?
Take one claim at a time. If they say the design was complete, identify the stated requirements and the missing failure modes. If they say they led the project, list the decisions they owned and the coordination another engineer supplied. If they say incidents were outside their control, separate external triggers from choices in design, testing, and response.
Ask the engineer to interpret each artifact before giving your conclusion. They may notice a weakness themselves, or they may reveal context you missed. Then state your assessment plainly. Do not soften a meaningful gap into “we just have different perspectives.” Managers owe employees a real standard, especially when review outcomes may differ from the employee's expectation.
What does good look like on the next task?
Translate level language into visible evidence. For the next service change, good might mean documenting failure modes before review, resolving major comments without repeated prompting, running a load test that matches production, and leaving an operator able to handle the first alert. The list should fit the role and task, not become a special obstacle course.
Ask the engineer to draft the evidence plan. This tests understanding without asking them to confess that their previous work was poor. Review the plan together and agree where you will inspect progress. A shared standard before delivery is fairer than arguing about quality after every artifact is fixed.
Which comparison keeps the discussion concrete?
| Claim | Artifact | Standard |
|---|---|---|
| Complete design | Review and failure modes | Material risks covered |
| Strong delivery | Dates and rework | Predictable usable result |
| Project leadership | Decisions and owners | Team could act |
| Reliable system | Tests and incidents | Expected load handled |
The standard column matters because raw counts can mislead. Many comments may reflect a healthy review, and one incident does not prove weak work. Explain why the artifact supports your assessment. Compare against the role's written expectations and similar complexity, not against an ideal that nobody meets.
What should you do if they reject every example?
Slow down and ask what evidence would change their view. If the answer is nothing, name that as a separate concern about using feedback. Do not start piling on more examples in hopes of winning through volume. Summarize the two assessments, the standard you are responsible for applying, and the next work sample that will produce new evidence.
If they challenge a valid inconsistency in your standard, take it seriously. Perhaps another engineer received praise for similar work, or requirements changed after delivery. Correct unfair comparisons. Manager credibility grows when revision follows evidence. It does not require abandoning a sound conclusion merely because the listener dislikes it.
What review sequence should you use?
- State the self assessment and your assessment.
- Choose one important claim.
- Inspect the related artifact together.
- Compare it with the written standard.
- Invite missing context or disagreement.
- Define evidence for the next task.
- Set a review date before final delivery.
Schedule the follow up while the next task still allows adjustment. A design checkpoint is more useful than waiting for another incident. Agree that you will review failure modes on Thursday and the completed result two weeks later. Frequent evidence reduces the emotional weight of one final rating conversation.
How can confidence remain useful?
Do not ask the engineer to become uncertain or quiet. Confidence can help someone make decisions and persist through complex work. The goal is calibration: claims should track evidence, and confidence should make room for correction. Recognize where their judgment is strong so the conversation does not imply that every positive self assessment is suspect.
Model calibrated language yourself. Say what you know, what you infer, and what remains unclear. For example, you know that retry behavior was missing and contributed to recovery time. You infer that review preparation was rushed. Ask about the inference. This demonstrates the evidence discipline you want from them.
How do you conclude the dated follow up?
At the next review, compare the agreed evidence rather than revisiting personality. If failure modes were complete, major comments were addressed, and the load test passed, say that the work met those parts of the bar. If significant gaps remain, explain them before discussing any formal rating. No one should have to decode the manager's facial expression.
Ask the engineer to assess the new work first and show their evidence. Improvement includes both stronger output and a more accurate account of it. A person can still miss the mark while becoming better calibrated. Name that progress, keep the performance standard intact, and set the next appropriate action.
How can you calibrate without turning the task into an exam?
Keep the next assignment normal for the role. Do not add unusual documentation, extra reviewers, or impossible precision merely because the engineer disagreed with your assessment. That would create evidence of how they perform under surveillance, not how they perform at work. Use the same design and delivery expectations you would apply to another engineer handling similar complexity, and explain any added check that the known risk genuinely requires.
Invite the engineer to choose comparison points. They may bring a prior design they consider excellent, a level example, or a similar service owned by another team. Compare the relevant qualities rather than arguing about reputation. Does the design cover failure behavior, operational ownership, and migration risk? Does the implementation require repeated repair? A concrete comparison can teach a standard more effectively than a manager repeating that the work is not there yet.
Watch for selective evidence on both sides. The engineer may emphasize a clever algorithm while ignoring the late rollout. The manager may emphasize an incident while ignoring months of reliable operation. Build the assessment from the whole agreed result. Quality can include correctness, maintainability, delivery judgment, and how easily another engineer can operate the system. State which dimensions matter before using them.
If the engineer improves the work but still describes it too generously, separate output from calibration. Say that the new failure analysis meets the standard and that their claim of organizational impact is not yet supported. If their self assessment becomes accurate while the output remains weak, recognize the clearer judgment and continue coaching the technical gap. These are related skills, not one verdict.
Before the formal review, summarize the evidence in writing and invite factual corrections. Include the claims you agree with, the claims you rate differently, and why. Do not make the engineer guess which examples survived calibration. A transparent summary reduces surprise while preserving the manager's duty to make an assessment. It also creates a useful baseline for the next dated conversation.
What if the rating difference affects promotion?
Say that plainly before the promotion decision is final. Explain which level claim lacks evidence, which evidence is already strong, and what opportunity remains in the current cycle, if any. Do not invent a last minute assignment that no other candidate had to complete. If the window has passed, state that timing honestly and create a fair plan for the next cycle. The engineer may feel angry because their self assessment and your earlier signals do not match. Review whether you gave vague praise, avoided correction, or described development as optional. Own any management failure without changing the evidence standard after the fact. A sentence such as “I should have told you in July that operational readiness was below the next level; the current evidence still does not support promotion” is painful but credible. Provide the written level expectation, the artifacts discussed, and the decision route. Avoid arguing that the engineer should simply trust your judgment. They should be able to see how the judgment was formed, even if they disagree. Set the next follow up around a real piece of work and commit to giving evidence while it can still be used. Better calibration comes from frequent comparison, not from one annual contest between confidence and authority.
What are common questions?
Should you tell someone their work is mediocre?
No. Compare specific claims with artifacts and the role standard, then state your assessment in precise language.
Can peer feedback be used?
Use relevant observed examples, not a vague claim that everyone disagrees with the engineer.
What if the engineer has strong confidence?
Keep the confidence and improve its calibration by requiring claims to track inspectable results.
How do you define what good looks like?
Choose observable evidence for the next real task, such as covered failure modes, resolved review concerns, and usable operations.
When should the next check happen?
Check during the next task while changes are still possible, then review the completed result on a named date.
Related: having a difficult conversation with an engineer, talk to someone who puts themselves first, talk to someone who never owns a miss.
Prefer prepared conversations over memory alone? Explore iSilta features or try the product demo.