What I'm Reading When I Write Your Performance Review
Five things that shape your rating but do not show upthe evaluation form.
One of my engineers once asked me, “What do I need to do to get a top rating this year?”
They expected me to talk about delivering small tasks and big projects. Their assumption: after they finish those projects, they will get a good rating.
Yes. That’s roughly half of the rating.
One thing I need to clarify: performance review is more than the delivery. Delivery is what you have completed. That’s the visible part, so engineers work hard on it.
The other half is a set of behaviors you demonstrate and opinions I form all year. They get compressed into words like “ownership” and “reliable”. That’s the part that gets more discussions.
I want to walk you through five things I’m reading when I evaluate an engineer.
The First Thing I Read
The first thing I do when starting the evaluation season: checking last year’s evaluation result.
Improvement areas, new expectations, and what we agreed that you’ll be working on. That serves as a baseline for the next evaluation.
One issue that comes up often: many engineers move on from the last cycle and ignore the last evaluation result. This potentially results in the same problem being spotted in the next cycle. And this is how it’s usually interpreted: a one-cycle gap is an incident. The same gap two cycles in a row is a pattern, and patterns are much heavier as a disadvantage in the next evaluation.
My Past Mistake
I made this mistake before as an engineer. I once received a comment: “Adler clocked out on time without resolving urgent issues, leaving customers waiting without notice.”
I had a different perspective, thinking that going home on time is my right. I didn’t try to resolve it or find a workaround with my manager such as handing over the urgent issues to others. I left the problem hanging there, insisting on my work pattern. I ended up getting the same feedback in the next cycle, which directly impacted my rating.
On the other hand, making improvements from the feedback is an easy win. Your manager already told you what they need to see. You demonstrate proactiveness in making improvements. Showing them improvements is a low-effort, high-return move.
Difficulty Matters, but Not the Most
“The harder the problem, the bigger the achievement”. That’s what I used to believe.
It turned out to be half-true. Similar to how people measure outcome vs output, scope is the deciding factor for how big the achievement is. Usually, the difficulty level goes up as scope gets bigger. For example:
Handling a small code refactoring => helping yourself
Handling requirement ambiguity => helping developers who are working on that feature
Coordinating among teams for a technical solution => helping multiple teams
However, there are exceptions:
Spotting a division-wide technical issue that your team already has a solution for => pointing it out and presenting it, low effort, big scope, high impact 👍
Refactoring a module only two people touch => high skill, high effort, but small scope, low impact 👎
What managers are evaluating: how large a problem can you take on before someone needs to break it down for you? This is how they use the career ladder to match achievements against expectations. Scope, rather than difficulty, is the deciding factor.
When you pick the next task, also keep in mind: the same work scores differently depending on where you sit on the ladder. A mid-level engineer solving an ambiguous problem with no spec is performing above their level. A staff engineer doing the same thing is performing exactly at their level. It’s expected.
The Cost of Managing You
Another factor in performance review is how autonomous you are without your manager needing to interfere.
For example, same two engineers, same project. One needs three check-ins a week and a Slack nudge before every deadline. The other handles everything as expected and raises any concerns before I have to ask. Both delivered, but the difference is clear.
You’re being scored on whether your manager can stop thinking about you.
Some evaluation questions you can ask yourself:
Do risks reach managers early, or do managers find out when it’s already late?
Do managers have to verify your status updates?
When managers hand you something ambiguous, do you move it forward, or does it stall?
When I was an engineer, my manager asked another member to investigate a data inconsistency issue across two teams. That engineer started checking connections between two services.
After some time, they finally found the root cause, a legacy pattern in the other team. They reported it back to my manager, and then… simply stopped. They didn’t want to go further because digging into the historical reasons required asking another team to collaborate. That created a lot of hassle, so they just stopped.
Managers understand it’s not easy, but it’s exactly this kind of opportunity that demonstrates whether someone can handle issues on their own. When they stopped, the manager needed to follow up. If they had gone further, it would have shown that their management cost stays low even when facing challenges.
Note that this part is subtle. It could show up in the performance review as very specific feedback about this occurrence, but it could also sit underneath the “reliable,” “trustworthy,” and “ownership” that a manager writes.
The Five Percent I See
I probably see only five percent of your working life. I’m not in your pull requests or DMs. Most of what you do, I never see directly.
It’s a little unfair, but for myself and most managers, that five percent gets assessed far more heavily because it’s a direct impression. Not from your self-assessment, not from peer feedback, but from myself.
One example comes from our team’s daily standup meetings. I don’t care much about people missing standup occasionally. Things come up. If people skip once or twice, I don’t notice, and I don’t want to be the manager who does.
But one engineer on my team was gone for more than a week (WFH). I asked them about it, and they had a reason for every single day. Their internet connection was unstable. A family member was visiting. They had a personal errand. Something at home needed handling.
Every reason was valid, but it became suspicious when all of them happened over ten working days. When they weren’t there, the questions that needed them were left pending. Someone needed to chase them afterward. Multiply that across two weeks and the team was spending quite some time handling their absence.
I’m not telling you to put on a performance in front of your manager. What I’m describing is less extreme than that, and it’s human nature. What managers see directly does have a bigger impact during evaluations. It might not go into the evaluation feedback directly, but it could create bias or start an investigation about how you behave around others.
The Third Opinion
Peer feedback might have a larger impact on the performance review than you expect.
Most peer feedback I see is shallow and polite, but sometimes there is sophisticated and constructive feedback written by kind people. They play an important role in evaluation.
In general, managers always ask for a third opinion, since they’re not in every meeting or Slack thread. Peer and stakeholder feedback fills those blind spots.
There are cases where an opinion from a respected stakeholder can create a new discussion. I once saw an engineer being discussed during a calibration meeting. He seemingly got along with everyone, but one staff engineer provided the feedback that he was stubborn and didn’t listen to advice. Someone caught this feedback and asked for further investigation before we finalized the rating.
The result didn’t look good for him. We found several occurrences where he didn’t address concerns from stakeholders properly before moving on with the solution. If it weren’t for that peer feedback, he could have gotten a better rating.
In most companies, peer feedback is not part of the official feedback process, but managers usually still use it as a reference. They ask about member A when they talk to member B, collecting ideas about how each one is doing, from a different point of view.
Last Words
None of these are pointed out directly on the form, but they are all included in the evaluation in some way.
The truth is, most managers won’t say them to your face, either. “You cost me more attention than you’re worth” is not a sentence managers would dare say. So it gets translated into something softer, such as more ownership or stronger communication.
Those phrases sound vague because they’re a summary of a hundred small observations handed to you without going into the details.
Now you have the list. The next time you hear one of those phrases, you know which of these five it came from, and you know what to ask about.
Thanks for reading this post!
I’m currently writing my Performance Review Survival Guide, which goes deeper into all of this. It’s a short ebook told from the manager’s perspective: what we look at, and what most engineers miss.
Before I finalize it, I have one question for you:
💡 What’s the one thing about performance reviews you’ve always wanted to understand from your manager’s side?
Drop it in the comments or reply to this email. I read every one.
See you in the next post.
Adler from Tokyo Tech Lead