"Exceeds Expectations": How to Hack Performance Review and Consistently Get High Ratings
A candid guide on how the performance review process really works in IT companies, and how to strategically position yourself to consistently receive top ratings.
Performance Review Is Not About Work
I'm a professional performance review passer. And while this might sound like a joke article, I'm not joking at all.
Back in my Sber days, your final rating directly determined whether you'd get a full annual salary as a bonus, half of it, or just be happy for your colleagues. It wasn't just a corporate ritual — it was a real sport.
Maybe I have a perfectionist syndrome, or maybe I'm just a competitive person. Or maybe I realized early on that performance review is a separate skill that correlates weakly with actual work.
Just to be clear, this article is not about cheating the system — I don't want to close off my path back to big tech. This article is about how the system actually works, even if we pretend otherwise.
Performance Review Is Not About Work
Performance review is about the impression you make, how you look in the eyes of your colleagues and your manager.
You can grind all year and get "meets expectations." Or you can do a couple of the right things at the right time — and suddenly "significantly exceeds expectations."
Let's break down what actions are needed for that.
You Need to Activate at the Right Time
The main rookie mistake is being consistently good throughout the entire quarter or half-year, depending on how often performance reviews happen.
Nobody cares about that.
The right timing is the last month before the review. This is exactly when the manager:
- starts collecting feedback
- recalls who did what
- forms the overall picture
And then you suddenly come alive and start performing. You start writing updates, asking questions, bringing ideas, carefully reminding people of your presence.
From the outside, this looks like growth, engagement, and maturity.
And the last fresh impression is very important. Just imagine doing the opposite: performing at the beginning, then fading out… think about that.
Don't Be a Jerk — On the Importance of Being Pleasant
There's a myth that in IT people value directness, toughness, and "telling it like it is." That's not true. People value those who are comfortable to work with.
I had a colleague on my previous team — a QA engineer. And she was incredibly comfortable to work with. She had this unusual enthusiasm for helping figure out requirements or testing corner cases. She always responded quickly and seemed genuinely happy about any communication on seemingly boring tasks. She didn't have super deep technical knowledge, she didn't write automated tests yet and was a manual tester at the time. But I always gave her the highest possible ratings and sincerely wrote about how great she was during performance review. Because she was simply comfortable to work with, and I didn't care how many tickets she closed in the last cycle.
If you:
- don't roll your eyes
- don't dismiss other people's ideas
- don't start every discussion with "actually, that's all wrong"
Then you're already in the top 20% of the team and will at least get good ratings from your colleagues.
Performance review is always subjective. And a subjectively pleasant person beats a subjectively unpleasant one, even if the latter is technically stronger.
Solve a Problem Outside Your Responsibilities
If, for example, you work within a single team as a regular member, you can take on a task outside the team — within the cluster or even the entire company. I've done this many times, and it was always different things: I created interview assignments, improved the design system, introduced new libraries for the entire project, or solved architectural problems at the large project level — filtering, performance improvements, and so on.
But it's important not just to do it, but then to describe it in vivid detail. You absolutely must mention that this was a contribution beyond the team. This will be one of the green flags for promotion. Managers have these conditional checklists they use to justify a grade or salary increase. If you made an impact beyond the team, it's easier for the manager to sell your promotion to their own manager.
Weaknesses Are a Trump Card Up Your Sleeve
You should always identify your weaknesses and try to address them within the cycle. At minimum — dig up one such point. Even better — prepare the ground in advance.
In one cycle, you can explicitly highlight your weaknesses. For example, write that you want to be more involved in product requirements. Then in the next cycle, actually take responsibility for a feature once and carry it to completion solo.
There can be many cases here:
- you're quiet and don't participate in discussions — start engaging and proposing ideas
- you've never participated in code review — start doing it
You get the idea. You absolutely need some small victory over yourself.
Self-Review Is Not a Report, It's an Advertisement
If your company has a self-assessment stage — that's a gift.
You need to write about yourself not as an engineer, but as someone defending a project to an investor.
Each point is a mini-case: problem → action → result.
I always describe my completed tasks in self-reviews as if I saved the company. I didn't just "complete such-and-such an epic" — I "took complete responsibility for the epic, gathered and formalized requirements from stakeholders, implemented it, conducted testing, and delivered an important feature to the client."
This isn't lying. It's just corporate sugar or corporate magic — everyone understands everything, but the right words still produce the desired effect. Sometimes it's enough to simply translate your work into this language — and it suddenly looks twice as valuable.
Tell Them Yourself That You Exceed Expectations
Don't be afraid to say that you rate yourself above average.
After the rating, of course you need to back it up — use the previously mentioned strategies. Just try giving yourself a high rating and then pulling together a batch of supporting facts — there's always something to find.
It's easier for the manager to agree than to prove otherwise. Especially if you've given them ready-made arguments. And it's also useful to see how this looks from the manager's perspective.
How the Game Looks from the Manager's Side
Imagine you're a manager of, say, several teams. Usually higher-level managers make decisions about promotions. You get 20 people for review, people you haven't interacted with daily, just occasionally crossed paths with in meetings.
If someone gave themselves average ratings — "meets expectations" — then with 99% probability the manager will just say OK and toss them some breadcrumbs instead of a promotion. Because there are limits, and there are people who are literally shouting about how great their work is and how they're waiting for a promotion. And they might even get offended if they're ignored.
And then the manager looks at a self-review with a high self-assessment: achievements are spelled out, the person did this and that. Plus the team gave them good ratings too. How can you disagree with that? It's a different story if there's dissonance — for example, bad ratings from colleagues paired with a high self-assessment. Then it might not fly. That's why you need to follow all the points from this article.
Performance review is not about honesty. It's about framing and visibility. And one well-chosen heroic act. You can be a strong engineer and consistently get less than you deserve, or you can be a smart player. And honestly, if the system is like this — it would be a sin not to learn to play it.