For many people, the review process can be mysterious and intimidating. I hope this article can shed some light on what can seem like an opaque process.
What are Performance Reviews?
The first question is what exactly counts as a performance review? Every company will do things differently, but in general, performance reviews are the process where a company evaluates employees. Often, the goal is deciding pay increases and bonuses, though sometimes it’s just for the purpose of making sure everyone has a dedicated period where they get feedback. At some places the review process is more detailed, and the employee is expected to document every project they worked on for the entire year. Other times it is a lightweight process with the expectation that feedback has already been discussed throughout the year.
What Performance Reviews Are Not
It is important to note that feedback is not the same as a performance review. A great example of this is the Connect process at Microsoft. The Connect process is a time to collect feedback and reflect on the last Connect period (which usually around a half year). The Connect process is to encourage employees to take an honest look at how they can improve without worrying about how it might affect their end of year review.
Feedback is something that should happen multiple times per year regardless of the review schedule. While we do formal feedback twice a year in my organization, I try to do at least one 1:1 dedicated to feedback with my direct reports per quarter to make sure they are tracking towards their goals. In general, you want to avoid surprises during the review period so if your manager isn’t supplying feedback, you should feel empowered to ask for it.
Performance reviews can also be different than promotion reviews. It’s often the case that reviews are done once a year to decide stock awards and bonuses, but promotions can be done multiple times throughout the year so that people who were close to promotion don’t have to wait an entire year for another chance to be promoted.
Phases of the Review Process
Generally, the review process will go through a few phases that can take anywhere from a few weeks to a few months depending on the size of the company.
Data Collection and Metrics
The first part of the review process is getting all the data around what you did for the year, as well as how well you did it. Companies will vary in how involved this process is. It can range from no data collection, where the manager just gives you a review, to a weeks-long process where large amount of documentation is needed. Microsoft has simplified its process over the years from requiring a long document to having employees answer just a few questions.
Some companies have very concrete metrics used for review periods, such as number of code reviews done, number of PRs submitted, or number of bugs fixed. While this seems attractive because of its quantitative nature I have generally found that where there are numbers, people will game the system. If you are measuring comments on PRs, people will leave many small not useful comments. If you are measuring bug fixes, people will break down bugs into smaller bugs to boost the numbers. If you are at a company where metrics are used, make sure you know what those metrics are, so you don’t fall behind in any of them. While I don’t recommend gaming the system or looking at just the numbers (there are more valuable things to do as an engineer), it’s important to make sure you aren’t behind on any of them.
A note on the 360-review process
A very popular version of reviews is called the 360-review process. Although it’s called a review process, it’s just a name for collecting feedback from above you (your manager), below you (your direct reports if you have them) and beside you (your peers). That data can then be used to inform your review. I reality you can use this process whenever you want to collect feedback about your work. The 360 process is effective because often how you show up to each of those groups can be very different. I’ve been in situations where I rated very well with my manager and my direct reports but not my peers, or times when I haven’t reviewed well with my manager but do well with my peers and direct reports. Each of these groups see a different side of you so it’s good to collect feedback from each of them.
Calibration
For large teams it’s important to have a consistent bar across the organization. To do this, most organizations employee a process known as calibration where they discuss employees compared to each other.
Going into calibration, each manager will summarize their direct reports achievements and areas for growth to other managers. The format for this can vary from a multi-page write up to a 1-page power point summary (often know as a “baseball card” because it presents the persons “stats”). The goal is to have a format that can be easily understood by someone who doesn’t know the employee directly.
In the first round of calibration, your manager and peers will review everyone on the team discussing where each person is compared to others that are similar in level and experience at the company. There might be discussions around how a person has shown leadership, their technical abilities, or their contributions to team culture. The hardest part of calibration is that each person is different and provides value in their own way. Much of the time spent in a calibration is reconciling these differences.
A model that I really like for measuring performance is Microsoft’s 3 circles of impact:
- Individual accomplishments
- Contributions to the success of others
- Results that build on the work of others
These areas really capture the pieces necessary to be a successful engineer. They shift the focus away from individual achievement to a team-based mindset where people need to think about how they are influencing others.
In larger teams, calibration can happen at multiple levels. After your manager and their peers review their teams, the calibration process may go up another level to a director where they talk about the larger organization. In these cases, the conversation will be less about reviewing each individual and more about looking at edge cases (high performers, and people in need of support) and making sure each team is being consistent in how they calibrate their employees.
Review Committees
Some companies form blind review committees of people who are separate from the team to review employee “packets”. While this does prevent bias in some form, it can be dehumanizing and takes a lot of the nuance out of the performance review process. There is a lot of context that gets removed when reading just a write-up. If you are in this situation, when creating your packet, I recommend really staying in the mindset that the person reading the packet has no idea who you are. Read your packet as if you were a stranger and make sure you include relevant backing information. For example, if you write “I fixed 20 bugs this review period”, is that good? Maybe the average person at your level fixes 100.
Feedback
After collecting feedback and calibrating everyone, there is a debrief between the employee and their manager. The most important thing to do when this meeting is schedule is to get yourself in the right mindset to receive feedback. Receiving feedback is hard for everyone and it doesn’t help if you are stressed out about something else going in. Remember that whether you agree with it or not, feedback is a gift. It allows you to improve your performance, or the perception of your performance. If you are unappreciative of feedback, it’s very likely that people will stop giving it, and that will stunt your ability to grow.
The most important part about receiving feedback is avoiding getting defensive. Resist the urge to defend yourself, counter the feedback, or worst of all deflect or blame others. Put that energy into understanding the feedback and seeing what you can learn from it by asking questions. Remember even if you don’t agree with the feedback, it’s telling you that you either need to do better or represent your work better.
In an ideal world, you have already been getting feedback that matches what you just heard during the review process. However, unfortunately sometimes things come to light during the calibration process that make it hard to always have correct information beforehand. For example, maybe other people at your level had exceptionally strong results compared to you in the review period, or maybe there was feedback from your peers that your manager didn’t have access to beforehand. Being able to gracefully receive feedback and make others feel appreciated for giving that feedback is an incredibly important skill that can have a huge impact on your career.
Stack Ranking
Some organizations stack rank their employees as part of the review process. This is literally ranking each employee in order, generally with the goal of forcing them into buckets. For example, a company might say that the top 10% are high performers, and the bottom 10% are low performers that need to be managed out. Microsoft was infamous for doing this, but they have since abandoned this model because it causes competitive behavior that isn’t productive for healthy teams. People may not want to cooperate if they know they are being ranked against others.
It may sound small, but there is a big difference between a general calibration and stack ranking. Stack ranking is forced, and one person must be ranked better or worse than another. In a calibration process, it is perfectly acceptable if everyone happens to perform the same, there is no need for someone to be at the top and someone at the bottom.
How to work towards a good review
There are generally two hard parts getting a good review. One is making sure you are aiming at the right target. If you spend the year building your technical knowledge, only to find out your company cares more about impact and results you may not get a good review. Make sure that you know what criteria are used for review at your level and check in with your manager on a regular basis to make sure you are on the right track. This is especially important for companies like Amazon that have quantitative metrics, and those that have strict rubrics.
It can also be hard to keep track of what you did throughout the year. This is especially true for yearly reviews, where it can be difficult to accurately recap what happened many months ago. To make this easier, it can be helpful to have a running document throughout the year to track your work. When you get to review period, you can then just lift things quickly out of the doc and into your review. Another data point that I have found to be helpful is to go through your source control system and review the code you’ve submitted and bugs you’ve closed. You can also look back at your calendar for important meetings to help jog your memory of important moments.
Performance Improvement Plans
If someone has consistently bad reviews, they can be put on a performance improvement plan. At most companies this involves working with your manager to come up with a very specific plan to get you back to meeting expectations at the company. P.I.Ps get a bad rap when companies abuse them by forcing employees on them to make quotas, even when they don’t deserve it.
When done by a company that really cares about its employees, P.I.Ps can be very helpful. They provide both the clarity about the feedback (i.e., this is what expectations you did not meet) and a way to create a structured plan to get back on track.
Hopefully this has provided clarity on the review process. The most important takeaway is to check in throughout the year on how you are progressing towards your goals. It can be easy to forget about, or willfully ignore, reviews until it’s too late to make a difference. Reviews are an important part of professional growth, and they should be valued, not feared.