Are you looking for ways to give your developers more actionable feedback? A fresh look at feedback can help. Rethink your definition of feedback by trying different types, expanding what you give it on, getting some help and changing your mindset. Let’s dive in.
Give more praise
Your response to being asked to give more feedback might be to point out every little thing your team is doing wrong. A better response might be to point out everything they’re doing right! Pay special attention to code and designs and make your praise more actionable by being specific about the positive behavior and its impact. There’s some interesting research that puts the ideal praise to criticism ratio at 5:1! Take a look at some of your recent code or design reviews and count the number of negative comments versus positive. Sobering isn’t it? There are a lot of benefits to creating a positive workplace. If we want our teams to perform at a high level we should point out the specific things they’re doing well so they’ll do more of it!
Give specific appreciation feedback
The book Thanks for the Feedback describes three types of feedback: appreciation, evaluation and coaching. Appreciation feedback is sometimes neglected but it can be very effective. While a quick “thank you” or “good job” is nice you can do much better by being more specific about what you appreciate and its impact. There are lots of ways to do this but you can try something like: “Thank you for doing (specific behavior). It had (specific impact) which is important for (specific reason) and I and the team really appreciate it”. The exact wording doesn’t matter as much as being genuine and specific.
Which brings me to some words of caution that apply to praise as well: only give genuine praise and appreciation feedback! If you don’t mean it and say it because you feel you have to it could backfire.
Change your frame of reference
Do you have a top performer who consistently exceeds your expectations and keeps asking you for more actionable feedback? This is a great problem but don’t give up on giving them feedback. Try changing your frame of reference to a more senior role. If they’ve been there a year, think of what top performers look like with 3–5 years of experience. That should give you plenty of ideas for what to give them feedback on.
Some more words of caution: make sure to separate your evaluation feedback from your coaching feedback! If you tell them “you’re great and here’s what you can do better” the positive evaluation might get lost.
Give feedback on non-technical skills
Most of the feedback you’re giving software engineers is probably technical as it should be, especially for junior engineers. That said success as a professional developer involves many non-technical skills. Here are some good skills to give feedback on:
- Decision making. Having good judgment is a critical skill and giving specific feedback can help improve it. Should they refactor this code or put in a quick hack? Escalate the issue or handle it themselves? Hotfix this change or fix it in the next build? Think about the decisions that are most important in your organization and give them feedback on those.
- Communication. Emails, ticket/code comments, conversations with PMs or QEs. How many projects have failed due to poor communication? Tone, word choice, content, timing, style are all fair game for feedback and can really help your engineers become more effective.
- Recruiting/interviewing. Depending on your organization engineers might be asked to interview or go on campus with very little training. Interviewing well is hard! You can shadow interviews or have practice sessions to provide feedback.
- Technical presentations or public speaking. These skills are not super common at the entry level but get more important and common as you move up the organization. How’s their presence, content, and delivery?
- Meetings. Both participating in and running meetings is an important skill. Did they invite the right people, have a clear agenda, participate or encourage participation from all or proactively include remote participants?
- Collaboration within and outside your team. How well are they interacting with their team? What about other development teams, product managers or operations? Are they using effective communication techniques? Do they have a strong enough network and know how to leverage it?
Encourage your team to pull specific feedback from you
What better way to give people specific feedback on their work than to have them ask you for it? Try to get your team in the habit of asking you questions along these lines:
- I just did X, how would you have done it differently? Can you think of any other ways to do it?
- When I did X I was going for Y (e.g. I was trying to make this code cleaner, or I was trying to get this specific point across in this email). Do you think it worked? Is there anything you can think of that would have worked better?
- This was my thought process for this decision. How would you have thought about it?
- Here are some things I think I could have done better. What do you think? Did I miss anything?
If you’re not sure how to instill this habit try using transparency to communicate your intention. “I would like to give you more feedback but I’m not always sure what exactly would be helpful. If you could try some of these questions that would be useful.”
Once you’ve communicated your intention it’s out in the open and you can use feedback to reinforce it! Point out as often as you can when they should be asking you for feedback. They’ll hopefully get a feel for it and start making it a habit.
Change your mindset around feedback
Lastly, what may be holding you back from giving more feedback is your own mindset. If you worry about nagging, voicing an uncertain opinion, or demoralizing with criticism try thinking of feedback as a two-way mastery conversation. Mastery is a powerful intrinsic motivator. You can voice your opinion and be humble and curious at the same time! Tell them what you saw and how it affected you, get their side of the story and jointly explore how to improve. Think of your work as a craft and feedback as a discussion on your journey towards mastery.
Originally published on medium.com on January 31, 2020.