Today I wanted to jot down some notes on giving and receiving feedback from your team and in particular, discuss some real-life scenarios that prompted this post.

Goal of feedback

As a people manager, one of your primary duties is to provide feedback to your reports. The intention of feedback is to ensure the team operates smoothly as a whole and the individual operates to the best of their ability while feeling fulfilled at their day job. It can seem fairly simple from the outside but is extremely nuanced in practice. At the same time, it can be very fulfilling when done right.

Why is feedback important

The role of a manager is to ensure the team is firing on all cylinders and executing on the company’s vision and roadmap. At the same time, you also need to take into account each individuals personal needs and motivations. Feedback is best delivered by tailoring it to match what speaks to the individual. Some of the common motivations that I come across are:

• Personal growth - this can be in terms of more responsibility, better titles, more pay
• Engineering excellence - ability to spend more time on architecting things correctly, adding non-user facing features that improve software stability, addressing tech debt
• Autonomy - ability to drive the technical roadmap, improve developer experience, optimizing CI/CD pipelines, working on performance issues etc.

There is a perfect balance between ensuring that the individuals needs are met while executing on corporate requirements and that’s the dance the middle-manager plays. Also keep in mind, you are managing up and down and need to ensure both sides are on the same page.

This involves ensuring any and all distractions are removed, knowing fully well what each team member is spending their time on and ensuring there’s enough work lined up as well as providing feedback at the right moment.

When, where and how

As with everything else, there is a time and place for providing feedback. As a manager, you will have several avenues to collect and deliver feedback. However, I wanted to call out a few scenarios to help drive the point across.

Scenario 1

Feedback is very personal and it can be touchy to provide that in a public setting such as group slack channels. However, it may be warranted in some scenarios such as this. You would want to address it in detail privately with the engineer but you would also want to step in and recommend that they don’t do that in the same channel – in context.

Doing so sets the tone for everyone else in the team. There are a couple problems with this behavior:

• It is not the responsibility of this senior engineer to get a status update. If they are blocked and need something, stand ups are a great way to address those. If they have a pretty cordial relationship with this junior engineer and there was already an understanding that they would ping them for updates over the weekend, that could have been a DM. The public team slack channel is not the right place to ask for such updates.
• Additionally, being silent when this happens tends to send the message that the leadership condones this behavior and sets the tone for team culture. Meaning it is okay to ping team mates on non-critical items over the weekend, which adds undue stress. No one likes being followed-up on, particularly over the weekend.
• It also sends a confusing signal about the chain of command and whose responsibility it is if this project fails to meet the deadline. Ideally that is not the concern of your senior engineer and they shouldn’t be bothered by it at all. Project delivery and commitments are the managers job. The engineer is shielded from that kind of stress and is enabled to do their best work on the ticket at hand. It is your job as the manager to determine when to ask for a status update and how that informs the delivery of your project. Allowing anyone and everyone in the team to take the responsibility is counter-productive.

Where: In context - in the same channel and in a personal 1:1

How: Explain what the role of the engineer is in the grand scheme of things. Help them understand how doing this is inappropriate and how it can add a lot of stress to the other teammates. Try to understand why they did this in the first place. Are they stressed about the delivery or did they not think about what they were doing. In any case, express gratitude about how invested they are in the project and help course correct.

Scenario 2

You would want to address that in-context as well. Adding a follow up comment in the PR – something to the effect of “I agree with the technical feedback, but let’s chat about your tone” helps let the others know that you are keeping an eye on things and addressing issues before they turn into problems.

A lot of times, people come from a place of wanting to be helpful or not realizing how they come across as. So this is definitely a teachable moment. A lot of tone is lost in text and you would want to let the offending engineer know this privately - DM or 1:1 call.

However, addressing in context sends a message to the rest of your team on what’s tolerated and what’s not. It encourages team mates to bring forth other qualitative issues that they may be experiencing.

These sort of experiences make or break the job. You spend the majority of your waking hours and most productive time of your day at the job and it needs to be something you can enjoy or at the very least not be adding undue stress. Focusing on the quality of the team’s experience is a major part of that.

Where: In context - in the PR and in a personal 1:1

How: Try and understand where this person is coming from. Explain how they are coming across and what the implications of that are. Seek to understand what motivates this person to behave this way and see if there's a way to channel that energy in a more productive way. Identify opportunities for them to exhibit this change.

Scenario 3

Where: Address it in standup when updates are being provided

How: Identify what’s taking them long and what would be the best way to help them out. Sometimes it’s pair programming with someone else. Other times, it’s a complex task and needs more time - so reevaluate sprint commitments.

Scenario 4

Where: Weekly 1:1s

How: Identify why this person feels there needs to be more investment. Sometimes it is objectively a requirement. Other times an individual may be too invested in the code they wrote. In that case, explain how their time and effort is better spent focusing on moving the roadmap features along and see if there’s any way this work can be tended do at a future down time if it is absolutely needed.

Scenario 5

This is an excellent scenario to really get ahead of things. These asks are inevitable but you can really optimize by having a difficult conversation up front. Once this project has been delivered on, you will be back to picking up all the pieces and there is a huge cost to that kind of intense context switching. In order to deliver on this one time-sensitive ask, a lot of other projects are going to miss being delivered on time. Take the time to identify the cost and be upfront about it.

Where: Grooming, Roadmap priority meetings

How: Show them the roadmap and make a clear case of what are all the projects that will be getting delayed, as well as the cost of switching contexts. Make sure you have a good understanding of how much work can get done each sprint and commit to the deadline accordingly. Projects like these are inevitable, however, the amount of stress they can add can be mitigated by being up front about the costs and making sure you are committing to the right scope of work.

Being proactive

Unfortunately, there is no silver bullet and you would need to determine what the right thing to do is on a case by case basis. Feedback is a way of shaping the culture of your team, it is imperative that you treat everyone with kindness and give them direct, actionable feedback and make sure that feedback is provided in time. Being proactive means not waiting for things to happen to provide feedback. Weekly 1:1s are a great way to help developers become more rounded and identifying opportunities for them to lead projects, attend conferences, or make good use of their time.

Feedback isn’t a one-way street.

Asking for feedback is a great way to learn where you and your team’s blind spots are. It is a good idea to encourage all your reports to talk to their skip-level manager and have them provide you any feedback. This is a great way to help the team provide you feedback without it feeling like confrontation. Anonymous surveys are a good way too, but they can be pretty time consuming. There are a lot of tools to manage team feedback and we will look into those in a future post.