Giving effective feedback can help your direct report be more productive and motivated. I’ve noticed that leaders fall into two groups. The first group are leaders who know the importance of feedback but find it difficult to be direct. The second group are leaders who are not afraid of giving feedback but have been told they’re too direct.
The model I use to provide feedback that is kind and direct is the Get-Give-Merge-Go model. It has never failed me. My coaching clients have also used this model with great success.
I’m assuming you’ve done the relevant investigation and collected data, or examples to back your feedback. If not, you should start with the Investigate step.
Investigate the feedback
One of the first things you should do first when someone gives you feedback for your direct report is to investigate if that feedback is a personal bias or feedback that is important to deliver.
You can:-
- insert yourself in meetings, pair program etc so you can observe their behaviour
- collect feedback from their peers
- look at their current and past work (e.g. github repo, past projects documentation, past code review comments)
Once enough context and data have been collected, use the Get-Give-Merge-Go model to deliver your feedback.
GET – Get them to share what happened from their perspective
The GET is to get their perspective about a situation or project. This is a critical step that will allow them to be heard FIRST. Once they feel they’ve been heard, they are more likely to be open to what you have to say.
If you skip this step and start with giving them feedback, their defences will go up, almost as if to protect themselves from imminent danger.
No matter how well you deliver the feedback or how well-intentioned you are, trust can be eroded and for some employees, building that trust again is much harder.
So, don’t skip this step.
GIVE – Give them your perspective of what happened
GIVE is where you share the situation from your perspective. This is where you explain with specific examples, data, first-hand observation how their behaviour had a negative impact.
It is important to stress here that your feedback should be about how their actions and behaviour created negative consequences, not them personally. For example, not “You are a terrible software engineer.” but rather, “The code you’ve committed created a severe performance issue.”
MERGE – Both parties ask questions to understand both perspectives further
MERGE is where both you and your direct report come together and ask questions to understand both perspectives better. This allows your direct report to explain their situation further in light of the new information from you.
Ideally, this is also the stage where they’ve gained further insights as to why their actions or behaviours created the negative consequences.
In some cases, they’re not able to come to that realization. You can then explain the situation differently, allow them the space to ask you questions until they understand. If they don’t understand how their actions or behaviours had a negative impact, any further conversation to change that behaviour will be useless.
GO – Guide them on the next steps
GO is where you help them come up with action steps to either correct or prevent similar situations from happening. The goal of this stage is that your direct report should leave the meeting with the realization of the impact of their actions and specific things they can do to change their behaviour.
If appropriate, this is where you can add a timeline for their action steps or an expectation of when both of you will connect again to follow up with this feedback.
Here’s a fictitious example of a feedback conversation using the Get-Give-Merge-Go model.
[GET]
You: Hey Joe, how did you feel the status meeting went this morning?
Joe: It went okay. It was a bit slow to start but I think everybody knew what to do by the end of the meeting.
You: What do you mean by “slow to start”?
Joe: Well, nobody seems to be speaking up until much later.
[GIVE]
You: I see. I’ve observed a couple of times in meetings where you interrupted other team members and started assigning tasks to them without their input. Can you tell me more about that from your perspective?”
Joe: I started assigning because I wanted to make sure the team is focused and we get things done quickly.
You: When you interrupt others and assign tasks to them without their input, it doesn’t motivate them to work on this project even though you have the best of intentions.
[MERGE]
You: Does that make sense?
Joe: If they felt differently, they should have said something. But they didn’t.
You: Is it possible that they may be afraid to speak up?
Joe: Maybe. But we’re a team. They should just tell me. I can’t read minds.
You: Did you ask them?
Joe: No…
[GO]
You: How would you approach this differently next time?
Joe: Maybe instead of assigning tasks right away, I can ask them first. Maybe I can ask more open-ended questions instead of making assumptions.
You: That’s great. How about we chat again next week and see how this is going for you?
~~~
To follow up and help them grow, you could attend the next few meetings to observe their behaviour and continue to provide feedback, especially positive ones. Positive reinforcement is great to help provide the feedback that they are on the right track.
Lastly, be patient. Behaviour change is not easy especially for team members who are used to behaving in a certain way and especially so if this is the first time they’ve received feedback.
Photo by Charles Deluvio on Unsplash