Continuous Feedback
I was sitting in a business communication class one night after work, while I was working on my MBA. Our professor played a TED talk by Mike Robbins on authenticity. Mike tells a story about a time he was facilitating a meeting at a bank that wasn’t going well because there wasn’t trust in the room. He stopped the meeting and led an exercise where everyone was challenged to be vulnerable and share with the group how they were feeling. Eventually people started to open up, and the story ends with someone giving their boss some direct, critical feedback in front of the entire team. After the video, our professor asked the class who could see candor like that happening at their company? Looking around the quiet room, I realized that I was the only one with my hand raised.
I love working in a tech org that focuses on continuous improvement. We don’t want to make the same mistake twice, but how do we know if we make mistakes if we are not getting feedback? Sometimes the feedback is somewhat automated: errors in prod or customer complaints. However when we are working closely with teammates in pair programming or mob programming environment, some of the most important feedback we can give each other is on the way we communicate and behave as members of a team. We don’t just want to continuously improve the code but also ourselves to be better teammates and collaborators.
Formal feedback
Periodically, we solicit formal peer feedback. Everyone has the opportunity to give written feedback for their peers, letting them know what they are doing well and how they can be more effective. The feedback is then distributed to the team members, and the team is encouraged to talk openly about the feedback they received with their teams, whether it is in one on one meetings or as a whole team. Discussing the feedback allows us to get clarification on areas that we aren’t sure about, allows our peers to know their feedback is heard, and helps us hold each other accountable for areas where we want to improve.
Before I came to Pluralsight, I couldn’t picture this happening. It sounded made up. I will tell a little story to illustrate what these meetings look like.
The Tale of Feedback
Sally, Bob and Sue work closely together. They wrote feedback for each other and are meeting to review it. It is a 30 minute meeting so each of them will have 10 minutes to talk about what is on their minds.
It’s Sally’s turn.
Sally: Thank you all for your thoughtful responses. I feel like you were dead on in so many areas and I learned a lot from reading these. Bob, I noticed that you said that I can ramble when I am presenting ideas. Are there certain situations that you notice that more often?
Bob: Actually yes, I have. I notice it more in bigger groups, especially when there are people from other teams there. I think you want to be sure to give enough context, but sometimes you go on longer than needed.
Sally: That makes sense. Sue, you said something that aligns with that, when you noted that I seem nervous when speaking in groups. Is that the same rambling that Bob mentioned?
Sue: I think so. You dance around your points instead of going directly there. You have really good ideas but they often get lost when you present them.
Sally: I have been thinking about improving my presentation skills. It seems like I need to focus on adhoc comments as much as larger meeting presentations. Would you both let me know if you notice me rambling in these sorts of things?
This discussion continues, with Sally creating space for her team members to give her additional feedback or validate her strengths. When the time’s up, they move on to discussing the next person.
Adhoc Feedback
If you read that last section and thought, “hey that feedback isn’t continuous”, you would be right. If the only feedback we gave each other was the formal solicited feedback, we would be missing the point. Experiences like sharing formal feedback help to create an environment with enough trust that we can give feedback on the fly to each other. We challenge ourselves to give clear, direct, timely feedback to the people around us in the vein of Radical Candor.
This can take a lot of forms, from letting someone know you appreciate how they kept a meeting on topic to pausing a pairing session to determine how to make decisions collaboratively after things got a little heated. It is often easier to not give the feedback because of fears that you might hurt someone’s feelings or because you assume that they already know what you have to say. We have to keep reminding ourselves that because we care about the people around us, we want them to have the tools they need to improve.
It’s a gift
Feedback is one of the best tools that we have to improve ourselves. It can help us identify our blind spots, see the impact of our actions and be more effective in our roles. It can be hard to receive critical feedback, but it can also be hard to give that type of feedback. We owe it to the people giving us feedback to be attentive, respectful and thankful that they took the time to help us improve. We can ask for clarification or more details, but we shouldn’t start arguments. We want to make the person feel comfortable giving us more feedback in the future.
Feedback doesn’t have to be big. It doesn’t have to be hard and it doesn’t have to be scary. We can praise exceptional efforts and (privately) correct pain points, as long as we have trust on our teams. The feedback that we give each other is a gift that can help us all be better developers and teammates.