Giving feedback to software developers may seem challenging, especially if you don’t know what type of personality you are dealing with. But with the right strategy in place, it can become a tool for creating and maintaining a high-performing and engaged engineering team that yields results.
Confucius, in 5th century B.C., supposedly said:
Not speaking with people who truly can benefit from your words is to let those people go to waste.
Even though people have been discussing the art of giving feedback for centuries, we're still not good at conveying complicated messages well.
In fact, Gallup has found that only 26% of employees strongly agree that the feedback they receive helps them be better at work.
What are managers doing wrong?
I want to share with you tips for becoming an effective engineering manager who supports their team and helps employees become a better version of themselves.
Table of contents
Avoid Textual Forms of Communication
Although we live in an age where Slack is our go-to tool for everything from project management to small talk, it may not be the wisest option for giving constructive feedback to software developers.
Textual forms can be misleading. The employee may interpret your message in the wrong way, resulting in more complications than resolutions.
That's why, when delivering feedback to your engineers, avoid using misleading means of communication.
The better option is one-on-one communication. If you're a remote team, you can have a one-on-one meeting using a video conference tool such as Google Hangouts, Zoom, or another preferred software.
Why is video communication better than textual? First, it eliminates misunderstanding.
Second, when you meet face-to-face, you can form a personal connection with the employee.
Third, you can pick up on verbal and non-verbal cues like body language and detect how your message is being received. When you communicate your feedback via email, you don't have information about whether the employee will read your message.
A report by Forbes tells us that 62% of executives agree that video conferencing significantly improves communication quality. Also, 50% of those surveyed believe video conferencing also improves the degree of understanding.
The next time you want to give feedback to one of your engineers, set up a meeting in your office or on a Zoom call, and convey your words carefully.
Careful Planning Is Essential
Careful planning is the secret ingredient to all successful endeavors. You use careful planning when launching a business, hiking Mount Everest, or organizing a surprise party.
The same thing applies to when giving feedback to your software developers. After all, the employee will expect that you, the manager, are prepared for the one-on-one meeting.
Here are a few tips for how to prepare:
- If you don’t have regular one-on-one meetings, ask the engineer if they have some free time to talk. It can be something like, " Do you have a few minutes to talk about our last meeting?" Doing so will let the person know that feedback is coming. You're also leaving room for the employee to accept or postpone your invitation to talk.
- Clear 15 or 30 minutes off your schedule.
- Set up the meeting.
- Make sure you're in a quiet room or place where you can have a focused discussion.
- If it would help, prepare notes of what you would like to say.
- Have a respectful, fair, and understanding communication with the engineer. Strive to come to a shared understanding and view of the problem, and discuss potential actions for how to resolve it.
- Listen to the engineer's point of view. Maybe you'll learn the root cause of the problem, for example, a broken process. This will help you fix the problem and with that, improve the general performance of your team.
Don't Give Feedback That's Too Indirect or Too Direct
The reason why feedback is often ineffective is because of how managers convey it.
There are two types of managers, ones that give too indirect feedback, and ones that provide feedback that's too direct.
When a manager gives indirect feedback, the employee's brain may not even recognize that feedback is being given. The employee may feel confused about what the manager is struggling to communicate or how they should respond.
On the other hand, when a manager gives too direct feedback, it drives the employee to start acting defensively.
What should you do?
Give specific feedback with the person's culture in mind. It's simple: people from different cultures perceive feedback differently.
For example, when giving feedback to an American, a good approach is to focus on the positive thing first and then share the negative feedback, but do it very carefully. Chinese people are used to a far gentler feedback style than let's say, Germans.
A useful tip is to inform your team of the way you communicate feedback so that they know what to expect, especially if you work in a multicultural environment.
The second thing to remember is that you should always be specific with the negative feedback, as it's more delicate. Don't be too direct or too indirect. The best way is to be explicit with improvement points and have a direct discussion about potential problems.
Be Specific, Not Blurry
Have you ever had a one-on-one meeting with an engineer and said something like, "You should be more reliable," or, "You could be more proactive."
But what does that even mean? How can the employee know what you're referring to?
What an effective engineering manager would do is they will transform these blurry sentences into more specific.
For example, instead of saying, "You should be more proactive," they will say:
You said you would come up with some ideas for overcoming the issue with technical debt, but I still haven’t received anything. Is there some problem?.
Or, instead of saying, "You're not reliable," they will say:
I was expecting your email by Tuesday as agreed, but I still haven’t received it. What happened?
Giving specific feedback to software developers will help them identify which behaviors are appropriate or inappropriate for successful performance.
When you give specific feedback, you're actually telling your employee what they're doing right and where there's room for improvement.
In the long run, this can lead to higher performance, unlike less specific feedback that just informs employees of whether they are performing well.
Apply the Situation, Behavior, Impact (SBI) Framework
Imagine that you recently offered feedback to one of your Laravel developers. You told them that they possess outstanding technical skills but should be more proactive.
A few weeks later, you follow up with the person to find out why they haven't improved, as discussed during the meeting. You discover that they didn't understand what they can do to improve.
This scenario happens to thousands of engineering managers around the globe.
To avoid this scenario, it's critical for you and the employee to arrive at a shared understanding and a shared view of the problem and discuss potential actions.
How do you do that?
One popular method is the Situation, Behavior, Impact (SBI) framework.
The SBI framework outlines a simple structure that you can use to give feedback:
Situation
The first step is to define the where and the when of the situation you're referring to. This will give context to the feedback.
For example, you can say:
During your presentation last week, when we discussed accessibility in software development…
Behavior
Describe the specific behavior of the employee in the situation you're referring to. Make sure you only communicate the behaviors you observed directly and avoid mentioning hearsay. Don't make assumptions or subjective judgments about those behaviors. Simply note what you observed.
For example, you can say:
During your presentation last week, when we discussed accessibility in software development, Mike pointed out that you have a small error in your slide. Before he could even finish, you cut him off and became defensive.
Impact
The last step is to describe how the person's behavior has impacted you or others.
During your presentation last week, when we discussed technical debt, Mike pointed out that you have a small error in your slide. Before he could even finish, you cut him off and became defensive. I believe that this action may negatively affect the team's healthy functioning and can damage your relationship with Mike. What are your thoughts on it?
End on a Question
If you look at the example above, you can notice that we ended the feedback with a simple question, "What are your thoughts on it?"
That's my final point for today.
Ending your feedback with a question leaves room for a discussion. In fact, it's when the most critical part of the discussion begins.
From this moment and on, the conversation is no longer a monologue, but an opportunity for you and the engineer to offer possible solutions to the problem.
Final Word
What do ineffective and effective engineering managers do differently? Ineffective managers focus on short-term gains, while effective managers want to see their employees grow and thrive.
One way of creating a growing and thriving team is by giving feedback to your software developers. If we learned anything from this article is that feedback should be personal. It should happen during a one-on-one meeting, whether that's in an office or a Zoom call.
Be specific and rely on real data points. One method you can use is called the SBI framework, which can help you and the employee arrive at a shared understanding and a shared view of the problem.
Finally, end the feedback on a question and engage in a conversation.
