It’s another November, and another NaBloPoMo attempt. This year I haven’t ordered any Pokemon games to arrive halfway through the month, but given it’s 3rd November already, evidentially I’m not going to do a post every day. Consider your expectations managed!
Let’s get cracking with a tricky topic - giving feedback. Specifically, written feedback. At GDS this is meant to happen regularly: the idea is to ask our peers for feedback at least once per quarter, usually via a Google form, to help keep things asynchronous.
Giving feedback can be difficult!
- “I don’t have time!”
- “I don’t know what to write”
- “How do I bring up a bad thing without hurting their feelings?”
- “How do I bring up a good thing without sounding patronising?”
Lack of time is always an issue, but with a structure in place for the other three points, writing feedback can take less time. Also, the more you do it, the easier it gets.
I try and give written feedback to everyone that asks me for it, precisely because it’s difficult. It’s a skill that needs to be practiced, otherwise it gets rusty! There’s a caveat to this - if it’s my line manager or my line reports, I have plenty of opportunities to talk with them face-to-face, and writing stuff down would just feel weirdly formal.
So: how do I do it?
Keep notes
During feedback season, I keep a list of everyone who’s asked me for feedback, and jot down some rough bullet points as a brain dump:
MULDER:
- In depth knowledge of aliens
- Fearlessly takes on new projects
- Sometimes careless
- Doesn’t write anything down properly, that last file was unreadable
SCULLY:
- Good attention to detail
- Did a good job on that New Mexico project, good outcome for the team
- Often gives negative contributions to group discussion
- Great hair
I’ll add to these bullet points over a few days. Not everything makes the cut: if it’s just my opinion (eg Scully’s hair), I’ll keep it to myself. If it’s not constructive, I’ll reword it later: “Mulder could improve his documentation skills”.
IMPORTANT: Remember to minimise/close these notes when you’re not using them. We don’t want a screen sharing faux-paus.
When I’m ready to send the feedback, I’ll block out at least half an hour in my calendar to do it. I’ll then delete the notes for a person once I’ve sent it to ‘tick it off the list’.
Some feedback is better than none
Many people at GDS provide a feedback form with specific questions. If they’ve said ‘What did I do well?’ or ‘What could I have done better?’, believe that they do actually want to hear about those particular things.
However, if your feedback doesn’t fit the questions in the form, send it over in an email instead, or put it in the ‘anything else?’ box at the end, that your feedback requester should have helpfully included.
If you can only think of one point to say, say it and leave the rest of the form blank. Most people will be grateful for any feedback at all, even if it’s just “I enjoy working with you”.
Start with some compliments
If you’re worried about the tone of your feedback (or you want to soften a forthcoming blow), try starting off by picking three general traits about the person that are professionally valuable. Are they kind? Punctual? Organised? Reliable? Calm under pressure? Good attention to detail? Do they improve team morale with cute pictures of their cat?
If they fit any of the above, then say so! “You’re organised, reliable and calm under pressure.” It’s as easy as that. You don’t necessarily need concrete examples yet, but if you have them, use them.
Pick some examples
Now this is where you might have to do a bit of digging around in your Trello or Jira board - what pieces of work did you and the recipient collaborate on? Pick 2 or 3 and focus on those.
If you didn’t collaborate on anything directly, think about group discussions or ceremonies. How did they contribute? Did they come up with any cool ideas for improving things? Look at your retro boards and find out!
Example: “It was great to work with you on the Alien Invasion Alerting Service, your knowledge of Klingon helped us meet our team goals and get our surrender message out quickly.”
Suggest ideas for learning and development
If you’re in a leadership position or in a more experienced role than the recipient, make sure you suggest areas where they could take on more responsibility or gain greater knowledge. You can still do this if you’re not senior to the person, but there’s less of an expectation to do it.
The suggestions can vary depending on the recipient’s role. For software developers there is always something new to learn (sometimes too much!). Infrastructure is always a good area as it’s always changing, as is optimisation, accessibility, monitoring… You can tailor your suggestion to the project the recipient is working on.
Remember, there is no obligation for the recipient to actually do any of these! You are just suggesting something they might not have thought of.
Example: “I’d like to see you take a lead role on more infrastructure projects, for example upgrading our terraform code to the latest version.”
“What should I do more of?”
This question comes up a lot. At GDS there are a whole bunch of general things that we could be doing more of, regardless of roles: documentation, pairing, code reviews/QA, helping with recruitment, showing-and-telling, taking on a role during an incident.
Example: “Do more pairing - the less experienced members of the team would definitely benefit from your knowledge of the UFO Scanning API.”
Avoid statements like “try and speak up more in meetings” or “be more confident” - not everyone has the same communication style, and you can’t just flip a switch to turn on confidence. You know what gives people confidence? Your detailed feedback about specific things they’ve done well!
You can even go all meta: “It’d be great to see you give more feedback to myself and the rest of the team!”
If you are really stuck here, remind the recipient to look after themselves. I can’t think of a single person I know who is doing enough of that at the moment, including myself. We all need telling, especially right now.
Example: “Make sure you look after yourself and make time for your own personal development.”
Difficult feedback
Most people want to do the right thing and be good at their job. If they’re doing something irritating or missing the mark technically, they probably want to fix that! Be brave - a bit of short term awkwardness will make your life (and theirs) better in the long term.
If you’re struggling to write about a difficult topic, perhaps it’s better suited another format. Would you be more comfortable talking about it in person? Or emailing their line manager?
Example: “Hi [line manager], I have some feedback for [recipient]. They’ve done a great job on the Alien Invasion Alerting Service and I’ve given them positive feedback for that via their Google Form. However I’ve noticed that sometimes they’re not very thorough when reviewing my pull requests. We misspelled a crucial line in the recent peace treaty doc which had a negative impact on the team. It’s a little awkward for me to say this to them in person, so I hope you can pass this on anonymously, as an area that they could improve on in future.”
Difficult feedback could be a whole blog post on its own, really, but this post is already too long. Let’s wrap up.
Actually remember to send it
PRESS SEND. This step is vital!
People will often give a deadline for submitting feedback, but even if you’ve missed it, send it anyway. Found a file full of notes from 6 months ago? Have a look through and see what’s still relevant. Then send it!
Tit-for-tat
Your colleagues are not asking for feedback for the fun of it. Your feedback will help their professional development, figure out if they’ve met their objectives, or help them set new ones. You are doing them a big favour here!
Bask in that warm glow of benevolence. If you make the effort, chances are they’ll do the same for you in return.