In the spirit of the holidays, consider taking some time over the next few weeks, as things wind down, to write down some feedback for your colleagues.

Curious about what effective written feedback looks like? Look no further than this thread!
First, I try to use a ratio of 90:10 or 80:20 of positive:constructive feedback when I write it down, and I copy the recipient’s manager. If I have more constructive feedback, I deliver it in person, or in a private channel. Not all feedback needs to be on the “official record”.
(And on that note: if you deliver negative feedback, assume that asking someone, esp if they’re more junior than you, for a private impromptu 1:1 is going to be anxiety-inducing. Try to put them at ease, and consider asking for consent first if they’ve had a rough day/week.)
I start off my email with: “I wanted to record some positive feedback for ___, about her work on the team over the last three months.” Framing it this way tells the recipient and the manager that this is important, but not urgent, and not requiring action.
If you’re writing feedback for someone who has one or more URM identities, be very careful about giving non-technical feedback. Really try to avoid statements like “Kat organized the team dinner and she did a great job.” This might pressure Kat to keep doing non-eng work.
This genre of non-promotable work is called “glue work” and it disproportionately hurts women and minoritized people at review time. It’s too easy to write this feedback because this work is visible... and it crowds out feedback for women’s technical work. Resist this.
If someone did something noteworthy but not “technical”, then try to focus on the impact that the action had on the whole team. Sprinkle in some data if you have it. Ex: “Ella’s rework of the integration tests enabled us to cut the total pipeline run time by 30%!”
Be wary of giving biased feedback. Minoritized folks are way more likely to receive feedback like “speak up more!” — and also, “you should let other people speak more.” Challenge yourself to think of specific examples. Do other folks behave similarly, would you say the same?
I try to highlight 2-3 categories of feedback, and provide as much contextual detail as possible. Rather than saying “they’re great at refactoring” try to think of a really difficult refactoring task, and be specific about the ideas they contributed, and how they executed.
The purpose of this kind of written feedback isn’t primarily to course-correct: if someone really needs to change behavior, you should tell them as soon as possible, and consider using a framework like Non-Violent Communication if it’s difficult feedback.
Instead, I think about written feedback as the closest I can get to a historical record of growth, so that at review time, it’s less justifiable for subjective evaluation to smooth over parts of someone’s performance that managers don’t know, or don’t remember.
More resources:

Deeper explanation of glue work, by @whereistanya (who coined the term!)
Much credit to my friends Katrina Bakas and @nratniko23 who spoke about this topic earlier this year. No recording of their talk unfortunately but I tried to capture the content in this sketch:
You can follow @deniseyu21.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: