Lesson #19: How to conduct better performance reviews
Discover more from Lessons in Engineering Leadership
Lesson #19: How to conduct better performance reviews
Hello and thanks in advance for reading lesson #19 of Lessons in Engineering Leadership! Thank you to the 2,823 of you who have subscribed so far! If you’re new here, Lessons in Engineering Leadership is a bi-weekly(-ish) newsletter on a variety of engineering leadership topics that can be read in under 5 minutes.
If you would like to receive longer form newsletters and access to the tools I’ve created over time, you can become a paid subscriber.
I’m glad you’re here!
First off, some news!
I know it’s been a minute since I wrote a newsletter, which goes against everything I recommend around consistency in marketing. I’m currently preparing ~3 months worth of content to be sent out weekly instead of bi-weekly so you should (1) be hearing from me more regularly and more frequently, and (2) be seeing more paid long form content coming soon.
How to conduct better performance reviews
Ah, performance review season. ICs hate writing self-reviews, leaders hate writing both self-reviews and reviews for each team member – especially if there’s any constructive criticism involved or you have to rate your team on an arbitrary scale.
I can’t help what your company’s policies are around performance reviews, but I can help you write and conduct better performance reviews.
Address any recency bias at the outset. If your company follows a regular review cadence, you can easily begin to take notes of accomplishments and areas of opportunity for your team from day 1. This is important as recency bias (recalling only what happened most recently and giving recent events more weight than those that happened a while back) is a real issue with performance reviews. I keep a log of what each of my engineers has been working on from the end of one performance review season so I can easily pull from my notes when it comes time to write reviews.
Avoid the shit sandwich (coined by Ben Horowitz). Good-bad-good feedback is not helpful, as your team members will often focus on only one aspect of it (most often the end of your feedback) which generally leaves them saying, “wait, so am I doing a good job or not?”
Provide examples. You need to be specific in your performance review. Don’t vaguely talk about how they need to be better at communicating or they write good code. Providing more concrete examples also shows you’re paying attention and you care.
If your company allows it, share your feedback with the employee a day in advance. This gives them a chance to review it on their own time, but not so long before that they will sit and dwell on it over the course of a few days or so. This means don’t do this on a Friday if you can help it.
When sharing feedback (especially constructive feedback), confirm with them that they understand and give them an opportunity to voice their opinions or concerns. Don’t assume they understand what you wrote, especially if their behavior indicates otherwise.
Lastly, provide an actionable path for next steps - especially if they have areas they need to work on, but also for those who are high performers. Everyone has something they can work on. The best reviews are a launchpad for the next review cycle. Set concrete goals, and make sure they’re written down and visible to both of you. You can reflect back on these goals throughout the quarter (or half-year or year) to measure progress.
What I’m reading
I’m currently reading Iron Flame (iykyk), but I’m also reading The Art of Business Value. It’s a quick read and quite useful, especially if you are either a Product Manager or work with Product Managers.
Check out the full book list for recommendations and an ever-growing reading list.
Note: Links to books in this section are affiliate links to help support the purchase of the rest of my books :)
What I’m working on
Lately it feels like I’m working on my juggling skills. We just kicked off a new quarter a couple weeks ago so it’s mostly attempting to keep track of bleedover projects, new projects, contractual deadlines, and escalations. A lot of choosing which fires can simmer for a little while vs. what we absolutely need to get done.
If this email was forwarded to you, be sure to subscribe to receive bi-weekly emails in your inbox that can be read in under 5 minutes!