How to grow your engineers through continuous feedback

When I transitioned to my first engineering manager role, I felt a little lost and overwhelmed by my new people management responsibilities. One of the aspects I felt most unprepared for was helping people to grow and develop.

I decided to list out a set of high-level steps to structure how I would approach my reports’ growth and development. Here’s what that list looked like:

1. Raise and ensure self-awareness
2. Understand their concerns and motivations
3. Help defining the direction of their growth
4. Create the environment and remove impediments to their growth

In this article, I’ll focus on the first point of raising self-awareness. Self-awareness is a foundational aspect in a person’s growth. Before someone can know where they are going, they need to understand where they are.

I’m now several years into my management career, and I’ve discovered that the best way to raise self-awareness in teams is to foster continuous feedback. Here I’m sharing my unique method for continuous feedback, why I developed it, how I put it into practice, and what I’ve learned along the way.

The problem with discontinuous feedback

I had the idea to introduce continuous feedback to my team after noticing several problems with the common 360-degree feedback process my company was running every 6-12 months.

The issue with this approach is that it was very hard to remember anything that had happened more than a month before. The feedback my team was receiving reflected this, and didn’t capture enough valuable data to be meaningful. On top of this, folks were feeling overburdened by the number of feedback requests they had to respond to in a short amount of time, resulting in poorer and shallow contributions.

By giving feedback via forms, we were also missing out on the advantages of a two-way conversation. This left room for misinterpretation and lack of clarity, and most importantly, didn’t foster a culture of openness that is crucial to a well-functioning team.

The continuous feedback method

So, I decided to experiment with a different way of giving feedback that would tackle these shortcomings. There are many ways to approach continuous feedback, but here’s what I proposed to my team.

I challenged them to aim to collect feedback from two people every month. I would help them achieve this goal and maximize the value of these sessions. The process would have the following flow:

1. The team member identifies two people to ask for feedback that month, and discusses the reasons for the choice with the manager (me).
2. The team member approaches these people and asks to schedule a 15-30 minute 1:1 to discuss any feedback they might have on their performance.
3. The team member and manager prepares for these sessions together beforehand, working out what kind of questions or topics to focus on, and discussing how to receive feedback and dive deeper when relevant, etc.
4. The team member runs the feedback sessions and take notes, either during or after each session (depending on whether they can handle taking notes and conducting a meaningful conversation at the same time).
5. The team member compiles, shares, and discusses the notes with the manager. These results can prompt immediate action or inform an existing personal development plan (PDP).

Putting continuous feedback into practice

Of course, there was much that didn’t go exactly according to plan once we put it into practice. Over time, I iterated on the approach with many people and several teams, and developed some best practices.

Here are some of our key learnings:

• Consistency is more important than quantity

  Originally, I’d actually thought of suggesting more than two people per month. But I quickly discovered there is much more value in keeping this practice consistent over many months. Having just two people as a target makes it much more manageable to keep it consistent.

• You won’t exhaust the number of people you can ask for feedback

  “Won’t I run out of people to ask for feedback? My team only has five members.” Many team members have raised this concern. But the reality is that as software engineers, we interact with more people than we might realize. I challenge my team members to look beyond the feedback they are used to.

  Whenever we interact with a member of another team regarding some inter-team or project cooperation, that is an excellent opportunity to look for feedback. We could ask a product manager for feedback on contributions in a backlog refinement, or ask a site reliability engineer (SRE) we’ve been interacting with for feedback on our communication. Also, asking the same person a couple of months later can be great for validating the changes we’ve implemented after receiving feedback. Any meaningful interaction presents an opportunity to gather data about ourselves and improve our self-awareness.

• …or the number of topics

  My teams were also concerned that they’d run out of topics to ask for feedback on, or that doing it so often wouldn’t produce valuable output. But feedback can take many shapes and forms, and can be found in less obvious places.

  Beyond code quality and impact in delivery, we can focus on other aspects such as communication style and effectiveness, both in a 1:1 and in team setting. We can also tie these sessions with each individual’s PDP, and take inspiration for topics from there. These sessions can be used to ask for recommendations and advice from more senior colleagues about a topic we’ve been exploring, or to validate whether the improvements we’ve been trying to make are visible or having an impact.

• Help your reports to feel comfortable asking for feedback in a 1:1 setting

  Many people prefer to receive feedback asynchronously because they aren’t comfortable having feedback discussions alone with another person. This aspect of asking for feedback personally is one of the most crucial in the whole process, and fosters a culture of open dialogue, permission to fail, and true sharing in the long term. However, this discomfort is also very real, and common.

  This is why managers must have an important and active role in the process. When starting out, we can encourage team members to keep the sessions short and light in terms of content. Getting comfortable is the first goal. We can talk to them about active listening, and encourage them to practice it. We can suggest that they ask very simple and broad questions, such as the Start, Stop, Keep going model. Once they’ve got a few sessions under their belt, we can teach them how to ask for more directed and specific feedback, and dive deeper into certain topics.

• Organize your notes carefully

  Organizing the notes from all the feedback sessions over time has been another challenge. When I first started the process, I had my team members writing their notes on a single Google Doc. However, as the document grew larger, it became difficult to navigate and read.

  After some thought and experimentation, we arrived at the mind map format, using Mind42 (you can use another similar tool). A mind map is a diagram that allows to organize information into a hierarchical model. Each month, my reports add to their individual mind maps, either adding new threads for feedback topics that haven’t come up before (for example, communication), adding notes to existing threads that they’ve been working on (for example, code quality), or simply organizing the mind map by month and year. Being able to quickly collapse and expand information, and organize the information by date, topic, or another category makes the information much more accessible.

• Implement the feedback

  Another concern has been what to do with the gathered information. Feedback is subjective by nature, and we need to do some careful analysis to interpret it properly.

  It’s important to work with reports after the feedback sessions to help them come up with actionable follow-ups. By going over a high number of feedback notes together, we can identify patterns in suggestions for improvements, and make sure we’re prioritizing the right things.

The results over time

As with any process involving people and teams, the results weren’t immediate, and only became visible over time. The most obvious benefit started showing when our regular 1:1s were feeling more valuable, because we constantly had valuable points to talk about, plan, and action.

Another visible benefit is that performance review results feel a lot more predictable to both sides. Since feedback is collected and acted upon promptly, everyone is more aware of their areas of improvement and strengths.

One thing I didn’t expect was how much it would strengthen the social bonds within my teams. Not only has it been noticeable in retrospectives and other team ceremonies, but the day-to-day environment feels much more cooperative. People have started tackling user stories together much more often, rather than working alone. Even side projects, that were more of a solo thing, have started being shared and worked on together.

Of course, it hasn’t all been perfect. Some people have taken a bit longer getting comfortable doing 1:1 feedback sessions, and there are some people who have dropped it all together. But since this is something that the whole team (and sometimes more than one team) are doing, it’s easier to incentivize people to keep it going, or even pick it back up later on.

As a manager, the greatest challenge by far has been the hard work involved in educating people, and keeping them accountable and consistent in the practice. It certainly takes time and effort to actively contribute to the success of a new process like this, but it’s so worth it to see your team members develop their self-awareness, and grow as a result.