Writing the Performance Review

Most of the time, the formal review will be heavily skewed towards a written exercise: You will be required to write—not extemporaneously speak—your review, so that it can be part of a filed record. (Again, this is part of what makes it a formal review, rather than the more informal feedback session, which usually isn’t written except maybe in your notes.) Most engineering managers, if they came up through the ranks as developers, are not particularly comfortable with writing prose, which only adds to the stress.

Your HR team may have a specific format to follow; if not, consider that most performance reviews, regardless of position, are generally going to do some kind of assessment of the following:

• Communication
• Collaboration and teamwork
• Problem-solving
• Quality and accuracy of work
• Attendance, punctuality and reliability
• Ability to accomplish goals and meet deadlines

Lacking any specific format, you can structure your review to these six topics, each one covering a two-question format: “What did this person do well? What could they improve?” Or perhaps you prefer a more agile-retro-style start/stop/continue format: “What are the things this person is currently doing that they should continue doing? What things should they stop doing? What things should they start doing?”

Alternatively, go back to your stated set of expectations, and for each expectation, pull out concrete examples, and use that. Following some form of established structure helps you organize your thoughts, but the actual structure itself doesn’t matter as much (assuming HR doesn’t have strong opinions to the contrary).

The 3 Cs: One particular company I was a manager at chose to structure their performance reviews along a “3Cs” kind of angle, where each “C” stood for one of the areas of their review structure: Competency (evaluating somebody’s skills against the job requirements), Contribution (evaluating their work and contribution to the company’s overall goals), and Culture (measuring how much the individual adhered to, and contributed towards, the company culture). I advocate neither for nor against this particular structure, I only mention it as an example of how the HR team established a structure within which all performance reviews were meant to be cast (and that it was actually easier to operate within that structure than to try and create one of my own).

One element to keep in mind as you write the review is that of impact: Aside from the fact that this employee showed up and did their work, what sort of impact did they have on the team? On the company as a whole? Many senior-level executives don’t want to know how hard somebody worked, they want to know what results that individual was able to accomplish or achieve, so casting your review in those terms can make it easier for the senior execs to see the impact (which they, in turn, are often required to present to the Board as part of the company’s annual meetings or reviews).

As you write the review, make sure to avoid any statements that speak to the individual’s values, intentions, or character. The subject of the review is the employee’s performance, not the employee themselves. This may seem like a strange distinction, but really, it’s the same one we draw during code reviews; in a code review, the code is what’s under scrutiny, not the individual who wrote it. In the same way, we want to examine the performance and results of the employee’s work and how that relates to the expectations you set out in the beginning of the performance cycle.

Make sure you include both wins and losses in your review! Nobody has ever done a job without some stumbles along the way, and even the worst performers manage to get something right. Forcing yourself to look for the positives in your worst performers and the negatives in your best performers will help you deliver well-rounded reviews, but this is where your clear and objective expectations from earlier in the cycle will help you avoid purely-opinionated reviews.

Performance review meetings are not delicatessens! For quite some time, managers have been practicing the “sandwich technique,” in which the manager opens with a compliment, piles on a ton of negative feedback, then ends with a compliment, on the grounds that this somehow makes the whole thing easier to go down. It’s a stale technique, and while it’s true that an entirely “constructive” (meaning focused on what the employee can do better, and not at all on what they are doing well) meeting can send the wrong message, so can the “sandwich.” Imagine, for a moment, that you open the meeting with, “Everybody likes that you are pleasant and fun to be around,” then say “Your code is continuously a source of bugs and must be rewritten from the ground up every sprint,” followed by “The team enjoyed your dish you brought to the potluck last week,” you send deeply-conflicting messages about the relative weight and importance of all three of these things. If the employee doesn’t have a lot of “wins,” don’t hide that fact by making something up designed to make them feel better. Instead, end with a message that you see potential in them and that you are prepared to invest the time and energy into them to see them do better next cycle.

For most of your employees—the high performers as well as the ones that are solid—you’ll want to focus on their successes. Highlighting what competent contributors are doing well will further encourage them, and if they are in the optimal motivational outlooks, confirm to them that they are on the right track. Recognize—and celebrate—what they’ve done well. Again, be specific. It may be obvious to you, but employees may not always recognize their wins, so take the time to point them out along with the “why” of the win. “Rachel, you managed to get our external API documentation to a point where I’ve gotten a couple of compliments on it from our partners. That’s awesome. The fact that external partners are taking a moment to tell us how good our documentation is makes the company look good and improves our technical brand. Really well done, thank you.”

For those employees who are marginal (or worse), you’ll need to take a different approach. To start with, if you’re new to doing performance reviews, try to schedule these for after you’ve done your reviews of your exceptional and solid performers—you’ll want the practice of doing performance reviews before tackling the admittedly more difficult task of reviewing a marginal performer. Again, the emphasis should be on their performance, not the individual, and it’s generally best to get right to the point: “Joshua, I need to tell you that your performance isn’t meeting our acceptable standard.” Again, concrete examples are critical, and evaluation needs to be couched against the expectations laid out at the start of the cycle. Highlight the individuals “wins” where able, but if the individual isn’t meeting the bar, you’ll need to make sure they understand that, which you’ll do in the meeting itself—for now, your goal is lay out the judgment and evidence to support it.