It’s that time of year again and I’m asking for peer feedback and writing feedback for teammates and realized I’ve learned a few things about this process over the years that I think are worth sharing.
Asking for peer feedback
A close teammate and friend @kmcq gave this piece of advice recently and it really stuck and has made this review cycle at work much more straight forward and enjoyable:
One thing that I’ve found helps me write better peer reviews more efficiently for folks is for the requester to mention something that they’d like me to highlight: a project, quality, or whatever that I can speak to that adds evidence to what they’ll be writing themselves. This helps focus things and saves a lot of time.
I took that idea and ran with it and when I started asking my peers for feedback I included links to things I wrote or code I shipped that they could reference.
This greatly reduces the burden on the people you are asking but at the same time I don’t want to limit what they include in their feedback so my requests went something like this:
Would you be willing to provide me peer feedback? The feedback form has pre-defined questions but here are some potential areas from our IC expectations that I would appreciate feedback on and links to work related to those areas that I completed during this review cycle:
- Leadership and Communication
- Provides substantial technical leadership to help others learn and grow
- example 1
- example 2
- Technical Contributions
- Demonstrates deep knowledge of data – knows what data is needed, how to find new or missing data, connects disparate or ambiguous data
- example 1
- example 2
Typically when I provide feedback I focus it on just one expectation or project so you could just pick one of those examples above that you feel comfortable speaking to or choose something else entirely. Critical but constructive feedback is welcome and desired. If there is something I can be doing better for you or the team please don’t hold back.
I would of course be happy to give you peer feedback if I can be of service.
Writing peer feedback
I’ve been writing peer feedback two to four times a year for up to a dozen individuals for the majority of my 11 years at GitHub. Here are a few guidelines I use today that I’ve learned over the years.
First, when someone asks you for peer feedback ask them to apply the advice above! It’s a lot easier and faster to write feedback when the range of possibilities has already been narrowed down.
Second, address the feedback to them and not some third party like their manager. For example instead of saying “I appreciate how Rachel gathers requirements from stakeholders and delivers high impact results” say “Rachel, I appreciate how you gather requirements from stakeholders and deliver high impact results”. This feedback is for them! Not their manager.
Third, there should be no surprises when giving constructive feedback during a review cycle. What I like to do is reinforce feedback I’ve been giving during the review cycle and if at all possible provide examples of how I see them improving and encourage more of that behavior.