Reading Time: 10 minutes

This post is part of a blog series called Leveling Up: A Guide for Programmers. The series covers skills to learn more easily and more strategically as a programmer.

We recently finished a three-part series about giving feedback:

1. Evaluating Whether to Give Feedback
2. Identifying Safe Opportunities to Give Feedback
3. Framing Feedback

We are now ready to talk about how to receive feedback. We will do that in three posts as well:

1. Attracting Feedback (this post)
2. Receiving Feedback
3. Operationalizing Feedback

You’ll notice familiar themes between the posts on giving and receiving feedback. That’s because the frustrations of attracting feedback share a root cause with the frustrations of providing feedback. They’re two sides of the same coin.

Here is the main frustration we addressed in giving feedback:

We are often asked for feedback in the workplace, but if we do it “wrong,” then we can hurt our own advancement potential.

Here is the main frustration we will address in soliciting feedback:

We don’t get enough information about how others view us, nor how we can improve.

What is the connection between these things?

It’s that there is a large opportunity for downside for giving someone feedback and a lot less opportunity for upside. We have to be careful when we give feedback. We have to determine if it is safe, and we have to frame our feedback to minimize the chance of us getting blowback. Conversely, others have to be careful when they give us feedback. How will they know it is safe? How will they know how to frame their thoughts so that we won’t retaliate against them?

If we want people to give us more and timelier feedback, let’s make the process of giving us feedback as safe and clear as possible. Here’s how:

 1. Give them feedback first.

People want to reciprocate. Folks are more likely to give feedback to us if we have given them feedback first.

But to give other people feedback, don’t we have to return to the obstacle course of determining safety that we went over in the last three posts?

What if we don’t have time to check safety, or we want feedback from someone who we know is not open to receiving feedback themselves?

In this case, we can use a shortcut. Remember, our goal for now is not to give this person feedback that helps them: our goal is to get feedback from them that helps us.

This is where we can take advantage of the confusion we’ve discussed before between feedback and validation.

We talked about the difference between these in a simplified way in this previous post. Now we’re going to add nuance to our understanding of the distinction. “Validation” isn’t just “positive feedback,” to be distinguished from “negative feedback” (aka dangerous feedback).

Instead, when we validate someone, we agree with their assessment. If they’re proud of something, we congratulate them. If they have reservations about the performance of a component, we say maybe some work could be done to improve performance. Validation is feedback that provides the recipient with the following piece of information: “You are not alone in your assessment of this thing.”

Validation is not necessarily different from feedback. Rather, it is a type of feedback. Feedback encompasses other pieces of information as well, including things in our perspective that don’t agree with the recipient’s perspective. That disagreement is the feedback that helps the recipient the most, since it includes the things that the recipient cannot figure out alone. However, since it can be hard to hear, this is also the feedback for which recipients are most likely to seek retaliation, at great potential cost to the giver.

So here’s the shortcut: we can give someone validation and call it feedback. This maintains our safety and also establishes our status with the person as someone who is willing to give them feedback. We have not angered them or provoked retaliation, but when we ask them for feedback on us, the pull of reciprocity will make them more likely to respond with their “feedback”—a term, in their minds, that doesn’t exclude the parts of their perspective that disagree with ours, even though we only shared our agreements with them.

 2. Share specific goals and ask for feedback to reach those goals.

In the last tip, we discussed a nuanced definition of validation. In so doing, we revealed that when someone says “I’m concerned about the performance of this thing,” we are validating their assessment if we agree with it.

Here’s another, more familiar way to word what’s happening: by expressing their concerns about this thing, this person has made it safe for us to give our feedback about the thing. And get this: it’s safer for us to give our feedback regardless of what that feedback is! If we agree that the code needs a performance tune-up, then we express reservations with the person’s work but we validate their assessment. If we disagree and say the performance is good enough, then we disagree with their assessment but validate their work. In either of these cases our feedback makes the recipient feel validated. Safety achieved!

We can signal to others that they are safe giving us feedback on something if we express our desire to have that particular thing double-checked.

So, let’s ask folks for feedback on specific projects or professional goals.

There are three other reasons to do this:

1. Control your coworkers’ focus: suppose we want feedback on our technical proficiency, but when we ask for feedback, it’s overwhelmingly about our personality. This particular misdirection of feedback follows a very irritating pattern in the workplace, but it can occur with any misdirection: we might want to work on our people skills and only get feedback on our slick refactors. We can guide feedback toward the things we care about most by telling folks up front: “I’d like feedback to help me get better at X/accomplish Y.”
2. Make it easier for folks to think of examples: When we ask folks for “any feedback at all,” their minds can blank on the vastness of their experience working with us. When we instead give them specific goals, they can use that starting point to consider their perception of our skills or accomplishments and then tease out examples to help us understand why that is their perception.
3. Make it easier for folks to frame their feedback as an attempt to help: even when we ask for feedback, folks might hesitate on giving us “negative” stuff because they don’t want to hurt us (or get hurt). But if they have a goal that we are working towards, they can frame their feedback as “I think you could get closer to your goal by doing X instead of Y.” Now, instead of just bashing us, they’re helping us find the shortest path to our goal. If our colleagues want to help us improve, then this framing can overcome previously insurmountable barriers of getting them to open up about what we need to do better.

So, we can come up with one or two specific goals, assess ourselves on those goals, and share that with our peers. This will both reassure them and steer them toward the kind of feedback that will help us the most.

3. Reward colleagues who give us feedback.

We want feedback. People don’t want to give feedback because it carries a lot of risk and little reward for them. How do we change that balance?

We can decrease their risk by doing item 2 on this list: providing specific goals for them to help us achieve.

We can increase their reward, too: we can thank them for their feedback, act on their feedback, and make sure their superiors know what a positive influence their feedback had on our career trajectory.

First, thank them: this one we can do right away once we receive the feedback. It’s a small thing and it doesn’t necessarily impact their career, but that’s exactly the point. A “thank you” signals “you are safe providing me feedback: I am unlikely to seek retaliation against you for sharing it with me.” This will make them more likely to share frank feedback with us in the future,

Second, act on the feedback: if we act on their advice, we send the signal that we take this person and their judgment seriously. That tacit compliment goes a long way. We might also make the workplace a more enjoyable place for them. Maybe it’ll make us easier to work with or our code easier to approve.

Extra credit: explain how we will act on their feedback before they notice it. We can extend our “Thank you for this feedback” to “Thank you for this feedback: I see what you are saying about the way I rely on this unsupported library, and moving forward I will find another way to implement this functionality in future features.” This technique allows us to get some credit for acting on the feedback even before others notice that we’ve changed. In fact, mentioning it will help the feedback giver pick up on our changes earlier, so we’ll appear to be acting faster as well.

Third, publicly praise them for the feedback: take opportunities in the team meeting, in tech meetings, and in 1-on-1s to mention to others how the feedback giver has helped us improve at our mission-critical goals. We can even refer to their help as “mentorship,” which is a big buzzword for managers with regard to giving people accolades. We want to make sure that the feedback giver’s manager knows how much their feedback helped us. We want this person rewarded for doing the thing we wanted them to do: help us make the changes we need to make to reach our goals.

Conclusion

Giving feedback is a high-risk, low-reward proposition. So when we give feedback, we have to make sure it’s safe and then frame our feedback correctly. Conversely, when we want to attract feedback, we’ll get the best results by signaling that it is safe to give us feedback and by helping others frame their feedback in a positive way.

There are several things we can do.

First, we can provide them with feedback so they feel compelled to reciprocate. If we trust our coworkers, then this is a simple quid pro quo. If we cannot trust all our coworkers, we can get around this by giving our coworkers validation and calling it feedback, then later asking them for feedback in return.

We can also share specific goals with our colleagues and do a self-assessment of where we stand on those goals. This serves a number of purposes: it makes others feel safe giving us feedback, it focuses their feedback on things that are important to us, it limits the scope of examples they need to think about, and it suggests how they can frame their feedback as assistance rather than bashing.

Finally, we can maximize the rewards of giving us feedback by thanking people, internalizing their feedback, and acting on it. We can praise them publicly by accrediting them in our accomplishments and framing their work as having “mentored” us. When our colleagues see rewards from giving us feedback, that increases the likelihood that they’ll help us out with feedback again in the future.

That leaves the nagging fear, though: what if the feedback hurts? We address that in the next post on receiving feedback.

If you liked this post, you might also like:

This podcast interview with Greater Than Code

This post about tech leadership and responsibility

This post about protecting yourself in a tough work environment: especially relevant if you identified strongly with the idea of validating someone and calling it feedback. Written for women in male-dominated companies, but probably useful for anyone facing challenges at work.