This is a practical post for engineering and conveying effective professional feedback. We use it internally at Swimm as a guideline for how we prepare and convey feedback to our employees.
As part of my military service in Israel, I wrote syllabi and led many tech training programs. Years later, I founded Check Point Security Academy, where I mentored staff members on how to provide feedback to students. It was from these experiences that I learned the importance of feedback and how effective it can be when conveyed in the right way.
Today I’m sharing the process for preparing and conveying feedback with the growing number of developers and engineers at Swimm. I elaborate on creating sessions dedicated to giving feedback to developers that is neither a performance review nor part of a weekly/biweekly routine. Rather, it’s an event focused on giving professional feedback to your employees. I recommend having this kind of feedback session at least once a quarter with each developer on your team.
Why bother?
I have never met an R&D manager who does not have a to-do list that’s endlessly long. But preparing to give meaningful and practical feedback can and should take a fair amount of time.
We have all had the experience of receiving feedback that just went over our heads.
When engineered in the right way, feedback is an amazing tool. I argue that the time required is an investment in each of your developers is well worth the effort for three main reasons.
- First, feedback facilitates improvement. When developers know where they can improve and the areas they are doing well, it gives so much context and motivation to improve those areas.
- Second, feedback enables developers to be aware of their status. Too commonly, developers simply are not aware of their standing and performance in a company.
- Third, feedback is a genuine gift we can give our employees. As a manager, one of the unique things only you can do is observe your employee’s complete state and provide useful feedback. It is a unique gift that the employee can’t hope to get from any other source.
Developers rarely get professional feedback that can boost their careers, yet I have personally seen how much impact this type of feedback can have. It can help developers with their coding style, the way they handle their tasks (time management is not always something developers excel at), or even other things that impact how they are perceived by others (for example, their tone of voice in meetings).
How to engineer your feedback
To provide someone with effective and professional feedback, I would claim that the most important parts happen before the actual feedback session. Before that session, we need to carefully engineer it.
Keep track continuously
A golden tip is to always keep a list for each employee so that when something relevant for a feedback session comes up, you can store it and easily retrieve it later.
For instance, say your employee offered to help a team member during a daily meeting, and this is something you may want to point out later on, write it down with a date and context — just a few notes to jog your memory.
You should write down anything that may be relevant, even though you may later decide it’s not worth mentioning.
Gather all relevant information
When engineering your feedback, there are many things to consider (I provide a checklist later):
Review previous feedback sessions you may have had with your employee.Specifically, were there any action items? For example, perhaps the last feedback meeting focused on addressing edge cases in PRs. It is important to review where the discussion was left last time. Even if you would like to focus on something else, be sure to bring up what was previously discussed.
Go over your notes for the upcoming feedback session. As mentioned above, when you keep track of your employees on a regular basis, you can simply open your list and see what you’ve written since the previous session.
Go over relevant resources related to the engineer’s daily work routine.
- If you are providing feedback for a software engineer, a great place to look their work is the Git hosting service (e.g., GitHub), and specifically Pull Requests. When doing so, don’t look only at the merged version, look for the back-and-forth correspondences. Are there things that keep coming up on Code Reviews? For example, say that on almost every Pull Request, the reviewer notes an edge case that should be handled. This is something interesting to discuss.
- Go over your task management system — JIRA, Monday, ClickUp, or else. What tasks has the engineer been working on lately? What can you learn from it? You should consider how many tickets (or story points) the engineer has accomplished in the past weeks or months, and how different it is from the previous feedback session, and from other team members. In addition, consider the style of tickets this engineer tackled. Are the tickets focused only on a specific part of the codebase? Has the engineer tackled (almost) only small tickets, (almost) exclusively really large tickets, or a combination? Would you like the engineer to focus on different kinds of tasks during the upcoming sprints?
- Notice the engineer during daily sessions. Are they clear when explaining what they have been working on? Do they ask for help when needed or too late in the process? Do they provide meaningful advice for other team members?
Write down as many observations as possible. While reviewing the different information sources above, just write anything that comes to mind. It could be about the way that person talks on daily sessions (a.k.a standup meetings), how fast they have been in making new contributions, a very specific coding-style issue (e.g., “you should notice how you name your functions”), or something more general such as working relations within the team.
Focus and concretize
Decide what is important to say. Effective feedback, whatever the context, must be focused. You want to include issues that come up more than once (for example, a code review note that keeps coming on many PRs), or things of great significance. The goal of the feedback is that the engineer takes something from it. Make your message clear by keeping it concise.
Find examples — For every topic that is important enough to discuss — find specific examples and list them. Many developers actually expect to get concrete examples, and failing to provide them might make you come off as disconnected and make the person reject the feedback. Concrete examples can consist of code snippets, specific tickets, PR correspondence, quotes from meetings or Slack messages. It’s not about creating a “big brother” effect, but they need to understand what you are referring to.
Also, think about how things can be better, not just what requires improvement.
The outcome of this stage should be an outline for the feedback session. In the next section, I will describe what this outcome should consist of.
The feedback session itself
I recommend following a rather fixed structure for the feedback session, but this structure can and should be flexible. It should serve you, and not vice versa — so if you don’t feel comfortable with it, definitely adjust it to fit your style.
Introduction
Start by explaining why you’re meeting; this can be brief, but remember some members of R&D teams may not have had the opportunity to participate in this type of feedback session. Be sure to explain why you think this type of feedback is important and how long you have set aside to meet.
Two-way feedback
You’ve done a lot of thinking and should have come to the meeting prepared to relate only to things that you regarded as important. For each topic on your list, make sure you:
- Review previous feedback (if applicable). If this is not the first time you are raising this issue, review the summary of what you had previously discussed. Best to agree on the context of where things were left last time before moving to new items.
- Ask for your employee’s reflections on the topic. This is an excellent opportunity to ask how they think things have been going about the specific issue you have raised. For example, you might say, “We talked in our previous session about handling edge cases. Do you feel you have made progress in that regard?” Or you might bring up a new issue that you have not yet ever discussed. For instance, if you want to encourage the employee to speak up more during team meetings, you can start by asking, “How do you feel during our team meetings? Are you comfortable with how much you are contributing?” Take time to hear their reflections and assessment. You may decide to modify your feedback based on their answer.
- Provide your feedback. Now it’s time to share your thoughts — the feedback you have prepared. Make sure you provide the concrete examples you collected in preparing for this session.
Further discussion before summarizing
After providing your feedback, ask the recipient if there is anything else they would like to ask. A feedback session should be an open discussion. Perhaps there is something very important for them that you haven’t addressed, and this is a great opportunity for them to ask for your opinion. Note that this should be done before summarizing the talk. The summary is important, and you want to use it to convey the messages that the recipient will take home.
Summarize the feedback session, together
To summarize the meeting, the most important thing is to ask — what do you take from this? The answer will reveal if you were able to convey your most important messages. It is a great opportunity to make sure you are aligned, and if not — emphasize the important messages you would like the recipient to take. Similarly, you should repeat back what you understand from your employee’s comments, to make sure you are aligned.
When relevant, also state action items that stem from the feedback. For example, you may have decided that the recipient should spend 10 minutes to come up with additional edge cases before submitting a Pull Request, or perhaps they should come up with one creative idea during the upcoming week.
After the feedback session — write a summary for yourself
Once the feedback session ends, you should write down everything that has been said, and emphasize action items. The most important thing is to be sure to follow up on these action items. For example, if you decided that on the next Pull Request the recipient should focus on handling edge cases, review their upcoming PRs, and provide some feedback that is focused on that.
Make sure you mark everything that will be useful for you the next time you prepare a feedback session.
Checklist
This post described various things to go over or pay attention to when constructing a feedback session. This checklist should help you make sure you go over them every time:
Bottom Line
Engineers deserve professional, high-quality feedback. It can help them hone their skills, and make them aware of where they need to improve and what they should be proud of. Too rarely do developers get the feedback and recognition they deserve.
I strongly believe that providing R&D teams with effective feedback is the ultimate gift for them and for you as their manager. You know as well as I do that not all conversations involving feedback always go as you may have planned.
When engineering your feedback in the right way, it has a great impact, and I am confident you will see the results yourself.
Feedback is a gift, and following the guidelines outlined in this post, I am sure you will benefit from this gift.
