Your Manager Already Decided Your Rating. You Just Don't Know It Yet.
Here's what impacts it before you even start writing your self-review, from a manager's perspective
I used to think performance reviews were a Q4 problem.
As an engineer, I assumed the review cycle was simple: you present your achievements, the manager reviews, and a fair result comes out. The rating reflects all the hard work that you did this year.
Now I’m a manager. That’s not how it works.
Managers don’t wait until the performance review season. The average manager-to-engineer ratio has been climbing from 10.9 to 12.1 in 2025. More engineers per manager means less time for each person, and performance opinions start to form on fewer data points, earlier in the cycle.
By the time you start thinking about your review, your manager is already 80% decided.
This post is about the patterns that shape that early narrative, and what you can do about each of them before it’s too late.
#1. Your Rating Is Already Forming
From the manager’s seat, performance reviews happen all year.
For myself, by mid-year, I already have a working draft for almost everyone on my team: who’s delivering and who’s struggling. The self-review process rarely changes that. It mostly confirms what I already think, unless I miss something big.
I try to stay objective. But bias and experience are hard to override. Once an opinion starts forming, it takes a lot of evidence to move it. For example, if an engineer accidentally took down the production database for 24 hours and the company had to issue a public statement, the negative impressions would likely stay until the performance review.
The window when impressions tend to form is any milestone evaluation like a mid-year check-in. These moments feel safe to most engineers because they don’t directly change your rating, salary, or title. However, they serve as a “drill” for managers to start forming opinions.
My suggestion: Throughout the cycle, request performance discussions from time to time. It should be a focused review. Share what you’ve been working on, then ask directly: “What’s your current thought on my performance? Is there anything I should be doing differently?”
Those conversations are helping you course-correct actions and plans moving forward.
#2. Output vs. Outcome
This gap between output and outcome is one of the most common reasons engineers get rated lower than they expect.
Output is what you completed: features shipped, PRs merged, tasks closed. Outcome is what changed because of your work, for the team, the product, or the business. Ideally, it’s something measurable, or tied to a KPI your manager cares about.
Here’s a concrete example of the same work, framed two different ways:
Output framing: “Completed the module refactor.”
Outcome framing: “Completed the module refactor. It reduced development time for any following changes by 2 hours.”
Same work. Different weight in a review conversation.
The engineers who get good ratings understand how their work connects to business’ goals, and they communicate it that way from the start.
This also applies to how you pick tasks. When you’re looking at the backlog, think about impact, not just interest or familiarity. A boring task that unblocks two other people often matters more than an interesting one that doesn’t move anything forward.
#3. The “I Work Hard” Myth
I have never once heard a manager argue for a good rating because someone worked long hours.
Not once.
I understand why it sounds like a good argument. Hard work is visible, and measurable in hours. Especially in Japan, long working hours are somehow encouraged in traditional environments. I’ve managed engineers whose only strategy for high workload is doing overtime. They take it as an honor.
Managers don’t actually see it that way.
What long hours tell me as a manager is that an engineer is choosing effort over strategy. Working hard and overtime for chasing a deadline once in a while is ok. But consistent overtime means that something else isn’t working: either we need to split workload, or negotiate the deadline. Using overtime to solve all problems is not sustainable.
Hard work is a starting point, but it’s rarely a leverage. The engineers who get promoted are usually those who made it easy for their manager to explain why they deserved it. They need impacts and outcomes, not just working hard.
#4. What Silence Signals
Some engineers give the bare minimum during 1-on-1s. Progress is always “fine.” They want the meeting to end as soon as possible.
This leaves very little transparency about their project progress and work patterns. And it’s a strong disadvantage: if your manager has nothing to say about you, they have nothing to say for you.
In calibration, your manager has to advocate for you in a room full of other managers. That conversation runs on specifics. What did this person do? What was the impact? If your manager can’t answer those questions with concrete examples, they can’t push back on a lower rating.
I learned this the hard way with one of my own team members.
He was working on a solo project to refactor a giant codebase. The technical complexity was high. Honestly, no one else on the team could have done it. Every week he sent a progress update, but it always looked something like: “Completed module X.” I couldn’t extract much from that for the upcoming performance review.
I didn’t pay close enough attention to what he was pulling off. When review time came, I gave him “Meets Expectations.” He was disappointed. I started talking to other engineers about his project. They told me it was clearly very challenging and had a large impact on productivity. They were right. I only understood the full scope of what he’d done after the review was over.
That’s mostly on me as his manager. But there’s a two-way improvement here.
The way he reported his work was functionally the same as silence. A small reframe would have changed everything:
Before: “Completed the refactor of module X.”
After: “Completed the refactor of module X. It was the most technically complex part of the codebase, untouched for three years. It unblocks the team from Y.”
The goal is to give your manager a highlight, something they can repeat in a calibration meeting. Complexity, impact, scope. One or two sentences at the end of your regular update is enough.
#5. Don’t Save the Big Ask for Review Season
Some engineers wait until the end of a cycle to bring up promotion. In smaller companies, that might work. In bigger companies with a structured career ladder, it usually doesn’t.
By the time you ask, it’s usually too late for your manager to do much about it.
I’ve seen this with two engineers in the same cycle. The first came to me right after the previous review ended. He said: “I think it’s time for me to move forward. What do I need to do?” The second waited until near the end of the cycle, when he felt he had accumulated enough achievements to start asking.
The first engineer got promoted. The second had to wait another cycle.
Promotions usually require preparation that takes months. Specific achievements need to be documented and framed, things like providing mentorship, participating as an interviewer, or leading a cross-team initiative. Those opportunities need to be arranged, sometimes weeks or months in advance.
The right time to have this conversation is at the start of a cycle, not the end.
Tell your manager early: “I’m aiming for promotion this cycle. What does that path look like from your perspective?” That opens a discussion. Your manager can help you set goals that map to the promotion criteria, steering you toward the right projects.
Last Words
Your manager can only rate what they can see. All five anti-patterns stop your manager from understanding what you’ve actually done.
Managers form opinions toward engineers all year. If you’re quiet or only reporting output, your manager is still forming an opinion. They’re just doing it on less information, filling the gaps with what they’ve observed and what they remember.
The good news is that solving these problems does not require doing more work. It requires making your work easier for your manager to understand. One extra sentence in your updates. One direct question before mid-year. One conversation at the start of the cycle instead of the end.
That’s it. Start there.
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