Performance Reviews - they're all about the story
It's February, which means that for many technology companies, you're either just starting or well into the first performance review cycle of the year. This brings self-reviews, peer reviews, and promotion packets. I've worked everywhere from tiny startups to some of the largest companies in the industry, and there's a relatively common theme. People dread performance review season.
Despite the universal sense of dread associated with performance reviews, these processes are integral to working at a company of any significant size. Therefore, it's crucial for everyone, both managers and individual contributors, to understand the process. In this article I share some of the tips that I've given to my various teams over the years, and used myself.
Before we start, let's dispel one myth. These processes are not 100% objective. Most managers would prefer them to be, if only to reduce the number of meetings and paperwork involved, but the reality is that humans wrote the guidelines, humans run the process, and humans decide on the outputs, so there will be some amount of bias.
Tell a story
Given that almost all performance reviews are about more than an objective review of metrics, at some point, someone in the process will be telling a story about you. In the case of a self review, that someone will be you, but it could also be your direct manager, but either way, there's a story to be told, so treat it as such.
The story you're trying to sell is that you have had a productive quarter/year/whatever, and you're a valuable member of the team. The STAR method is traditionally recommended for answering interview questions, but can also be valuable when crafting your story. Managers writing reviews for their teams can also rely on frameworks like "Situation. Behaviour. Impact." to help with the narrative.
The other thing to remember is that a self review of your performance is not a place for humility. You've hopefully got some great wins, and now is the time to be proud of them.
Track your achievements
A frequent problem with performance reviews is recency bias. When you sit down in front of a blank screen and start to write out your achievements, of course you'll better remember what happened last week instead of what happened six months ago.
One way to counteract this is to write a brag document. There's a lot of excellent detail in that link, but the short version is that every week you should write down your big wins and areas to work on. Maybe you unblocked a team mate, or shipped a feature, or got traction on a project. Doesn't matter, write it down.
Then, when months later you go to start writing your performance review, you suddenly have a wealth of material from which to draw from. Now the amazing win you had months ago isn't lost, it's there in your review. A brag document also helps you identify things you're struggling with over time, and hopefully correct them before review season.
Understand your impact
Every company and department has a way of talking about impact. If you work in Sales, that's almost certainly deals closed or revenue generated. If you work in Product Management, maybe that's features shipped and the speed in which that happened. If you work in Infrastructure, maybe it's users served, load time or lowering the cost of your infra.
If your company is in anyway organised around performance, they likely have a document outlining what's expected at each level. It's called different things at different companies, but it's probably one of "Career path", "Signal matrix", "Expectations grid", or "Levels document".
Whatever it is for you, find that document and weave it throughout your story. Doing this will allow leaders who are removed from your day to day work to quantify your impact and compare it to others in the company. It's important to combine the language from this, with the current focus of the company. An L5 might be expected to "independently ship code", but your company might currently be obsessed with "reducing page load time". So make sure to talk about how the code you "independently shipped" also "reduced the load time".
To show you what I mean, consider these examples
In Q4 2023, I shipped 24 pull requests against the widgets product, removing 2,000 lines of code from the codebase and adding 24 new tests
versus
In Q4 2023, I shipped 3 new features. I did it while making the codebase smaller and easier to debug, plus I made sure I code coverage stayed above 90%, leading to less downtime in the Widgets product.
Tell basically say the same thing, but the story they tell is very different. The first is just a recitation of metrics that might mean something to someone with context, but the latter makes sense to folks across the company, technical or otherwise.
Be proactive about feedback
One big part of telling a story, is having other opinions that validate your own. This is usually achieved through peer reviews, which is a fancy way of saying "how your co-workers think you're doing".
But at review time, lots of people are sending and receiving requests for this kind of feedback, to the point where many companies dictate a maximum number of peer reviews to avoid overloading the organisation.
This means that you might not get the input of people who you've worked closest with, and even if you do, they're writing so many of these that they might not include everything they should. And there's the recency bias we spoke about.
To counteract this, you should be proactive about getting feedback. Don't wait until review season, incorporate it into your brag document writing by asking colleagues for feedback as you're updating it. Then you can ask for targeted feedback.
Consider these two requests for feedback
Hey Jane, It's review season. Earlier this quarter we worked together on Project Raven. Any feedback you had would be appreciated!
versus
Hey Jane, since it's fresh in your mind, if you had any feedback on the planning session I ran for Project Raven this week, I'd appreciate it. Specifically I'm looking to get better at how I run these meetings, so any advice you have there would be great.
The first example is sent weeks/months ago, and is pretty vague, which makes it hard for your colleague to provide concrete feedback. The latter one is timely, clarifies the request you're making by asking for specific feedback, and is therefore much easier to respond to.
You should be able to show your data
Whilst it's important to write a concise narrative, it's also important to have the data to back it up. In the example above, I would make sure to have links to some PRs, details of the test coverage, graphs of the uptime for the product etc.
You don't need to include them in the actual performance document, but have them to hand for yourself.
Think of it as "Trust, but verify". Most people might not ask for it, but it's good to have handy, and it shows you're prepared when you do.
For promotions, hold yourself to the bar you're aiming for
When you're going for promotion, one thing I've seen people do over and over again when writing their review is to focus on how they're exceeding at their current level. That's obviously important, but for a promotion, I think it's more important to tell the story of how you're already meeting the expectations for the level above. It creates a narrative where of course you should be promoted as they're only recognising what's already happening. And in the case where you don't get the promotion, you're setting yourself up for a really strong rating at your current level, as well as demonstrating a pattern of achievement, which will help land that promotion at the next review.
Keep a copy for yourself
One last suggestion I have, subject to your company's policies, is to always keep a copy of your performance review documentation. Your self review, your peer reviews, your actual performance review from your manager, it's all important to keep a record of. And I don't mean "Oh I can get that anytime from the HR system", I'm talking about a copy somewhere you access them after you leave that company, like your Google drive, or even just emailing it to yourself.
It's unfortunately all too common these days for people to lose access to company systems without notice, and these documents will contain concrete examples of your impact which will help you understand your trajectory, prepare for interviews, identify growth opportunities, and more, so it's really just good practice to keep them safe and to hand. You'll never know when you might need them.