Giving Developer Feedback: 5 Steps for Engineering Leaders
Feedback can be so easy to get wrong...
It sounds like an easy part of the job but it can be a task filled with dread, anxiety, or worry. Engineering leaders tend to be overly sympathetic and cautious when it comes to giving feedback.
Of course, no body wants to hurt anyone's feelings or upset the team but leaving problems unaddressed can boil up to much larger issues.
Unfortunately, it's not uncommon in engineering for feedback to go undelivered, causing problems to fester and performance to degrade - leaving managers wishing they spoke up sooner.
In this article we'll be sharing ways you can deliver feedback to your team effectively without being overbearing, seeming like a micromanager, or taking feedback too far and de-motivating your team.
How NOT to give feedback to engineers
Woof. Tough day at the office.
Let's break down what went wrong:
- Bill didn't have time to prepare for receiving feedback
- "Andre isn't going to be happy" sounds threatening
- The feedback is vague and doesn't include specific examples
Lastly, the last sentence doesn't leave room to discuss or problem solve - leaving Bill feeling pretty defensive.
He probably doesn't feel great after that interaction.
How to give feedback to engineers
Inspired by this classic post, we use this framework at Haystack:
1) Seek permission
Before giving feedback, make sure the person is ready to receive it. Most of the time, this won't be an issue. But if they are having a bad day, they can delay. This helps both of you: they can take the time to prepare, and you can give feedback when they will be the most receptive.
"Hey Bill, is now a good time to share some feedback with you?"
2) Describe observable behavior with data
While it's fine to identify observable behavior batters, make sure to give concrete examples. Telling someone they "often" or "always" do something is vague, sounds an accusation, and puts them on the defensive. If you give examples, it's easier to discuss solutions.
"I've noticed that the shared component refactor may miss our original estimation - but during standups this week everything sounded on track."
3) Describe the impact
Be very specific when you describe the impact. This is important. Did it affect anyone on the team? Did it cause a larger issue or sour a client relationship? If you predict issues down the line, then you can note that impact.
"This didn't give Product much time to coordinate with marketing. I'm concerned that if this happens again, we could hold back company wide growth goals due to this miscommunication"
4) Own your feelings
Share how this made you feel. This shows that you're invested too. Make sure to make this its own step so it doesn't get confused with the previous steps.
"I felt frustrated because I couldn't understand why these changes came at the last minute. It made me wonder if my expectations weren't clear, or whether I had misunderstood our progress."
5) Come with questions, not conclusions
Be careful not to make too many assumptions. Present questions and be genuinely curious about the situation. Often you may find yoursef as a contributing factor to the behavior. Ask questions and understand the root cause.
"I'm curious: what do you think caused the last minute changes? I wonder if there's something that I'm doing which is contributing to this. How can we prevent this in the future?"
At Haystack this framework helps us get better, faster. We're constantly looking for ways to improve. You shouldn't have to worry about giving or receiving feedback on your team. It should be a safe place to air issues, brainstorm solutions, and get everyone working better together.
Did we miss something? Email us at hello@usehaystack.io!
Haystack helps engineering leaders identify burnout and team health patterns. Instead of guessing if you're improving, or constantly bothering your team for updates, simply use Haystack to get alerts in your inbox every morning. Plus a dashboard to track improvements over time.
.svg){kind=small}
