This is part three in a series Ellen Chisa wrote for her blog on her experiences at Microsoft and challenges with the Stack Rank performance review system.
This part proposes some elements for giving a great performance review. I’ve never formally reviewed anyone: this is based on observations of the reviews I’ve had and how I’d ideally like reviews to go.
When you go into a review, ideally both people already know how the conversation will go. Hopefully you’ve been having regularly one on ones (if not, maybe try out better one on ones!) Still, even when you know the general tone of how the review will go, it’s still uncomfortable to be surprised by details.
While the new detail might be important feedback, the review isn’t necessarily the right time. It would be perceived differently during a normal one on one. During a normal one on one the environment is much more low key – it’s easy to start a discussion. It doesn’t feel like a big deal, just an observation your manager has made and wants to talk about.
In a review, it feels much more important (even if it isn’t). An employee could instead feel like explaining their rationale and perspective would sound “defensive.” Bringing it up in the review could actually make it take longer to improve on that skill because it feels like a big deal, instead of an incremental improvement to make.
When you’re writing your reviews – try not to bring up examples you haven’t already discussed. Either search for an example you have talked about, or just leave it out. Save it for another meeting: one detail probably won’t greatly change the review. Hopefully waiting will make the employee more receptive, and make the review go more smoothly.
Focus on the employee’s self reflection first
Most review processes involve an employee self-reflection. Usually, a self-reflection consists of the employee writing about their performance – either in a few paragraphs, or through answers to a short series of questions. The self reflection often includes both facts: “what did you do?” and also feelings: “how did you feel about what you accomplished this year?”
I mentioned this in my earlier piece about the stack rank, but at Microsoft my review always started with a piece of paper that included my review score new compensation numbers. The rest of the review is about progress, but also is about justifying the numerical results. It starts both people off from possibly opposite points of view – an average review vs. “I don’t think I’m average!”
Reviews should instead start with building consensus. An easy way to do this is to start with the self reflection. Genuinely read it, pull out important parts, and ask about them. This can make the process feel like much more of a joint reflection on the year.
Plus, it establishes a shared baseline of how to continue the conversation. Once you both acknowledge how the employee feels about their work you can move on, even if you don’t exactly agree on the details.
Even if it’s a negative observation – it doesn’t necessarily feel like negative feedback. If the employee has already acknowledged it about themselves, you can meet at that point in agreement and go forward from there. Once you’re on the same side, it’s easier to work together on how else to improve: which really is the goal of the review.
Then focus on peer feedback
Many review processes also include peer feedback.
Once the you’ve covered how the employee feels about their work, it’s a great time to bring in how their coworkers are feeling. It also tends to feel more objective than feedback from a manager might. A lot of employees are more receptive towards knowing how they’re impacting people they relate to.
A great part about peer feedback is that it’s really more of a “show” than a tell. If you get feedback that’s specific: “a developer said they were blocked while waiting for you to complete the spec” it’s hard to argue with. There might be a good reason, but it’s pretty factual. Most employees don’t want to negatively impacted their coworkers getting things done.
Compare that to how it might come across if it came from a manager. If the manager comes right out and says “I think you’re blocking the developer” it’s not as clean cut. Did the developer have other things to do? Did they want a break? Was this really all they could do? It’s much easier to brush it off as being an assumption the manager has made.
If you’re a manager – make the most of peer feedback. Don’t necessarily just read it off in a list, but figure out how to use it to support the points you want to make. Need to encourage an employee to speak up more in meetings? Use the peer feedback of “that employee has really great ideas! I just wish he shared them more often.”
From the employee side, there’s a big difference between your manager telling you what to do, and hearing what helps or hurts impacting your coworkers’ ability to get work done. From the manager side, peer feedback is really what can help make the company great. You want your team to be working together and receptive to what their peers say. If that’s the case: show that it’s your priority. Focusing on peer feedback before your own indicates how important it is to you.
After getting through the self reflection and peer feedback, it’s finally a good time to address manager feedback. At this point, the employee has gotten to express how they’re feeling about work, they’ve had some time to internalize there are ways to improve, and are probably looking for suggestions and other examples to refer to.
As mentioned before, the manager feedback shouldn’t include surprises. A review is a chance to aggregate all the types of issues you’ve been working on throughout the year and put the feedback in one place. You might have talked about a huge array of things throughout the year. Normally, they wouldn’t all come up in one week. The review is your chance to mention them all together. It’s also a great way to show the progress that’s been made so far on those areas: even if they aren’t perfect yet!
Concrete + actionable ways to improve
Finally, the review should come with concrete and actionable ways to improve. Just as companies often suggest that employees write actionable/measurable (such as SMART) goals, managers should focus on giving actionable feedback.
For instance, in the example of blocking a developer, it would make sense for my manager to suggest different ways to prioritize work. Or a manager could recommend a coworker who prioritizes well that would be good to talk to. Try to think about how to actually help your employees work through the areas that were challenging during the year.
This is particularly important in companies that have “scored” reviews. While not everyone uses a stack rank system, many people still bucket employees (with or without quotas).
In that case, I think it’s important for an employee to understand what they would have done differently to fall in a different bucket. It’s good to show what would have been a step down, and a step up! Everyone knows it’s hypothetical, so the point is to learn and share – everyone knows that it’s just a supporting fact, and one detail might not change a full review. It helps the employee see what really does make a difference.
Ex: The reason you got a 2 and not a 3 was that you went above and beyond by going to X event to represent the company. If you hadn’t taken the initiative to do that, I think you would have fulfilled your goals.
Or, on the other side: In order to have gotten a 1 this year instead of a 2, you would have needed to take more initiative with testing. We were really in a pinch towards the end of the cycle, and some of your co-workers organized bug bashes and more dog food testing. That really improved the quality of the product overall.
Without having clear explanations of how and why an employee fits a certain score, or a certain level, reviews can feel a bit arbitrary. If employees understand where they fall in the spectrum, it’ll be easier to focus on developing the areas that need work, and figuring out how to thrive.
Reviews should tell the story of all the issues you’ve worked on with your employee throughout the year: how they’ve felt about them, how peers have been impacted, and how they can improve.
Today’s blog post is a guest post from Ellen Chisa, a product manager at Kickstarter in NYC.