I learned the importance of feedback and how effective it can be when conveyed in the right way at two particular snapshots in my own professional development: writing syllabi and leading technical training programs, and years later as a founder of Check Point Security Academy where I mentored staff members on how to provide feedback to students. Out of these experiences and now as the CTO and Co-Founder of Swimm, I’m even more convinced about the importance of providing effective developer feedback and am surprised that it is not more commonly widely discussed in companies.
In this post, I’m sharing the internal process we use at Swimm with the growing number of developers and engineers we’ve hired. At Swimm, we have these sessions dedicated to giving feedback for each employee as a set meeting schedule twice a year.
Why bother?
Providing meaningful and practical feedback requires a fair amount of time. On some level, the fact that R&D managers usually have endlessly long to-do lists begs the question of why even bother.
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.
I have personally seen the benefits up close – and the ways that effective feedback can boost developers’ careers. For example, it can help developers with their coding style, how they handle their tasks (time management is not always something developers excel at), and other areas that impact how others perceive them, like tone of voice in meetings.
How to prepare to give developer feedback
An essential part of providing others with effective professional feedback happens before the actual feedback session. In preparing for that meeting, there are many things to consider.
- Review previous feedback sessions (if any) you may have had with your employee. It is important to review what was previously discussed to determine whether or not you need/want to continue the discussion now. Specifically, consider any action items from the last meeting. For example, perhaps the previous feedback meeting focused on addressing edge cases in PRs. Review where the discussion was left and whether or not they have had changes to improve.
- Go over your notes for the upcoming feedback session. As a manager, one of my favorite tips is to keep a file for each employee so that when something relevant occurs vis-a-vis your employee, you have a place to store those notes and quickly retrieve them later on for the following feedback session. For example, if your employee offers to help another team member during a daily meeting and you want to remember this, you simply can go to your file and write it down with a date and a bit of context to jog your memory.
- Go over relevant resources related to your developer’s daily work routine.3.1. Review outcomes – specifically Pull Requests in the git hosting service. It’s important not only to look at the merged version but also the ping-pongs. Are there things that keep coming up on code reviews? For example, if on almost every PR, the reviewer notes an edge case that should be handled, this might be something to discuss in your meeting.3.2. Go over your task management system in JIRA, Monday, ClickUp, etc. What tasks have they been working on over the last few months, and what are your takeaways? For example, how many tickets (or story points) have been tackled? Consider the style of tickets: whether the tickets focus only on a specific part of the codebase; only small tickets, almost exclusively large tickets, or a combination? This evaluation will help you think about whether you’d like to see a shift to different kinds of tasks during the upcoming sprints.3.3. Notice your employees during daily sessions. Do your employees provide meaningful advice to other team members? Are they clearly explaining what they are working on and asking for help when needed? Or, in your estimation, is a request for help too late in the process?
- Write down as many observations as possible. At this stage, just write anything that comes to mind after you have completed the previous step: the way that person talks on a daily session (a.k.a standup meeting), how fast they have been in making new contributions, a particular coding-style issue (e.g., you should notice how you name your functions), or something more general such as working relations within the team.
- Decide what is worth sharing. Effective feedback, whatever the context, must be focused. I recommend mentioning things that come up repeatedly – for example, a code review note that appears on many PRs – or other things of greater significance. Be sure to include both areas for improvement as well as contributions that you appreciate and want to acknowledge.
- Find examples. The more substantial your input, the clearer it will be, and the greater the likelihood of learning, growing, and improvement. Find specific examples to frame the feedback for every topic you plan to discuss. Failing to give concrete examples may make you seem disconnected and cause employees to reject the feedback..
- Come with suggestions for the employee. It’s not enough to know what should be improved – we also want the recipient to have practical ways to make the desired progress. If you don’t have concrete ideas, you may wish to consult with a colleague before the meeting.
The outcome of this stage should be an outline for the feedback session.
Structuring the feedback meeting
At this point, you are ready to set up the feedback meeting. The structure for this meeting can and should be flexible; it should serve you, and not vice versa. So if you don’t feel comfortable with the suggested outline below, definitely adjust it to fit your style.
Introduction
Start by explaining the importance of providing professional feedback. Remember that your employee may or may not have had the opportunity to participate in this type of feedback session previously.
Two-way developer feedback
Remember that you plan to relay only things you regard as important in preparing for this meeting. For each of these topics you have prepared to discuss with your employee, I recommend following this simple yet powerful structure:
- 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 about 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?” Remember not to jump in with long pauses because you want 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 give the concrete examples you collected in preparing for this session.
Further discussion before summarizing
Feedback meetings should be open discussions. So before summarizing, ask if there is anything else they’d like to talk about. Perhaps something significant has not yet been addressed – and they may want your opinion, advice, perspective, etc.
During this part of the meeting, be sure to repeat what you think you are hearing your employee share – especially when you want to be sure you are really ‘getting it.’
Summarize the feedback session together
The summary is critical, and you’ll want to use it to convey the feedback that your employee will take home.
To summarize the meeting, start by asking what their takeaways are. The answer, in part, will reveal if you were successful in conveying your most important messages. This is an excellent opportunity to make sure you are aligned and, if not, to emphasize the crucial points and action items (if relevant) that were discussed. For example, you may have decided that they should spend 10 minutes to come up with additional edge cases before submitting a Pull Request, or perhaps come up with one creative idea during the upcoming week.
After the feedback session – summarize immediately
Once the meeting has ended, it is best to summarize your notes immediately. Write down everything you think will be helpful to remember in preparing for the following feedback session, including action items. If you have scheduled back-to-back meetings, build in the 10 minutes needed to write down these notes when they are freshest in your mind.
Be sure to follow up on action items in due course. So if the focus is on handling edge cases, make sure you review their upcoming PRs to provide some feedback on that topic.
Bottom line
Developers 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.
Not all conversations involving feedback go as you may have planned. The most important thing is to prepare before the meeting and then be an active listener in the meeting itself. I strongly believe that providing R&D teams with effective feedback is the ultimate gift for them and for you as their manager.
*****
Swimm’s developer community is expanding quickly, and we invite you to try out Swimm’s free demo to learn how Continuous Documentation is optimizing the software development cycle. With code-coupled documentation, development velocity is improved, and onboarding is faster, more efficient, and productive.
