As individual contributors, we get better at our jobs from pursuing programming education, tutorials, and reading. But to improve our solutions for our specific team, or to work better with that team, we often need feedback from our teammates. And this can be hard to get.

Not just because hearing feedback on what we should change about ourselves and our work is hard—though it is, and we’ll get to that later. But it’s harder to get other people to tell us what we’re doing wrong. People don’t want to give feedback. As we get promoted into positions of greater and greater power, the feedback we receive dwindles. Shouldn’t it increase? Aren’t our actions affecting our colleagues more now? Why do they talk to us less? And what can we do about it?

The thing is, it’s easy to ask for, and even want, feedback in a sort of theoretical sense. But soliciting and responding to feedback are, themselves skills. We need to learn them and practice them as skills, especially as we assume positions of leadership. But most of the time we don’t do that. 

“Oh, and tell me if you have any feedback!” 

It’s common for folks in leadership positions to constantly reiterate to their team “I want to hear your feedback! My door is always open!” But that doesn’t address the concerns that teammates might have about bringing feedback. 

First of all, the degree to which someone says they welcome feedback can differ a lot from how they actually react when presented with the news that they aren’t doing something right. Every manager I have ever had has theoretically welcomed feedback. When actually given that feedback, I have seen managers dismiss, double down, and disengage. One time I had a manager explicitly insist that his longtime friend and freelance business partner be interviewed by us, his team, before hiring the guy, because he theoretically wanted us to have a say. All four team members interviewed this candidate. In the interview evaluation meeting, all four of us said no. Our manager argued with us, started crying, sent us all out of the room, and then hired the guy anyway. Thank goodness we all said no, or else those of us who individually rejected the candidate might have experienced professional retaliation from our boss.

This is a big reason that feedback vanishes as people gain power: a powerful person can get people fired. Why should I risk my job to help someone else improve—especially if I don’t know whether they’ll even use the information?

“But I’m very friendly and approachable, Chelsea!” So, I believe that you’re friendly. But approachability is not a character trait—it’s a skill set. It’s time for us to treat it as a skill set and develop approachability as leaders on our teams.

“Fine. So what the heck are these supposed skills?” 

The first critical skill for leveraging feedback is soliciting it in the first place. “Let me know what you think!” doesn’t cut it for powerful people. Instead:

1. Ask people individually. Not in a group setting, and not as an afterthought as people are leaving a meeting. Sit someone down and tell them “I value your judgment and your perspective matters to me.”
2. Express specific goals or ideas on which you would like feedback. Examples include “This quarter I’m trying to work on transparency about our team’s future plans. Do you feel like you understand the direction our team is headed?” or “Lately I have been trying to make my code more discoverable for other developers. Do you feel like you could maintain my code based on having read it?” This narrows down the set of experiences that people need to search in memory for giving you feedback. You’re eliminating work on their end, which improves the likelihood that they can give you useful information.
3. Include a self-evaluation in your request. When your self-evaluation includes areas where you could improve, you signal that it is safe for other people to put you in the headspace of thinking you need to improve. That might look like this: “One of the things I changed from before was that I started sending out a weekly email about upcoming projects, but I suspect that might fail to clarify for individuals how each plan affects them. What do you think?” or “I am making an effort to document how to use this tool, but I wonder whether I can’t include some of this information as error messages in the code itself so that folks get notified right at the point where they need the information. Would you rather know up front or at the point of error?” 

The second critical skill for leveraging feedback is responding to it. Especially with feedback that is hard to hear, recipients often experience compounding anxiety: first, the anxiety of discovering that they have to improve, and second, the anxiety of having no idea how to respond. Having a prescriptive list of steps helps in that case. The list looks like this:

1. Thank the feedback giver. They have taken a professional risk to share this information with you. Do not critique their framing here. You cannot, right now, disambiguate your emotional reaction from actual issues with their framing. Even if their framing could use work, now is not the time to address that.
2. Say that you’d like to take some time to reflect on the feedback and come up with an action plan for yourself. This gives you points with the feedback giver for listening and acting, even when you haven’t done it yet. You also need some time to emotionally deactivate before you can mount a prudent response to the feedback.
3. Take that time. If it was really hard feedback, I recommend finding a peer of equal or greater power to you who will be your processing buddy. Ask them to sit with you while you talk about the feedback and help you understand and react to it—without judging you, but also without validating your anger. This support person can help you get from whatever the feedback was to an action plan.
4. Execute your action plan to respond to the feedback. This is an important step in demonstrating to your team exactly how much you mean it when you say you want feedback. I intend to talk more about processing partners and executing feedback plans in this online, self-paced workshop coming out later this year.
5. Praise and credit the feedback giver in public forums. Again, this person took a professional risk to give you the feedback. Make that risk worth it to them by contributing to their professional reputation. Do it in a team meeting, or in front of their boss, or whenever you receive a compliment from a colleague on your new, improved behavior or workflow. 

These two skills—soliciting feedback and responding to feedback—go from being tangential, to nice-to-have, to critical over time. We increase in seniority. Our jobs get more complicated. The genuine support and trust of our team becomes essential to getting our plans executed.

We don’t have to be naturals at skills like these in order to make good leaders. But we do have to explicitly practice them and treat them as an important part of our jobs. Luckily, like any skill, they get easier with time and attention. Feedback skills allow us to enjoy more influence and better technical outcomes from our decisions. (By the way, I give a talk on giving and receiving feedback, and this is a recording of a Q&A from one of those talks. It might answer some of the followup questions you have about feedback after reading this post.)

The post To improve as an engineer, get better at requesting (and receiving) feedback  appeared first on Stack Overflow Blog.