Transcript from Lecture: Giving and Receiving Feedback

Reading Time: 14 minutes

I recently published a series of posts about giving and receiving feedback in the workplace.

Evidently, folks have found them useful.

We don’t usually teach this stuff: we instead send people into the workforce and let them struggle until they figure it out.

One class at the University of Chicago is attempting to change that: Borja Sotomayor’s Introduction to Software Engineering class. Students in the course get hands-on experience with scoping features, delivering on commitments, continuous integration/deployment, and communicating within and across teams.

As a part of the course, students do rounds of peer feedback for other members of their team. To prepare the students for working on their feedback, the teaching staff for the course asked me to talk to the students about feedback.

Following is the full transcript of that talk, interspersed with the slides. All substantive differences between this transcript and the words I said to the class amount to crowd work.

I hope you enjoy!

Full Draft Transcript

Hi! My name is Chelsea Troy. I’m a software engineer and a data scientist. I’m currently teaching the iOS Development course in the Master’s Program in Computer Science here.

Most of the time when I speak and teach, I stick to purely technical topics. But today I’ll be talking about two important professional skills: giving and receiving feedback.

I’m going to tell you the things I wish someone had told me about feedback in a team setting.

First, let’s establish what we mean by feedback. What is feedback?

It’s:

A signal
from external sources
about past decisions
that informs future decisions.

A signal: There’s a useful tidbit of information in there. As opposed to noise, that doesn’t have that tidbit of useful information.

From external sources: This isn’t our self-assessment, which can be biased and can have blind spots. This is supplementary signal that we’re getting from somewhere else: sometimes that’s our test output, sometimes it’s our system logs. Sometimes it’s another person, and that’s the kind we’re focused on today.

About past decisions: This isn’t about us as people. It’s not personal. Sometimes it can sound personal, and it’s up to us to tease out of that, what decisions we might have made that resulted in this signal we’re getting. We’ll talk more about this later.

That informs future decisions: Feedback helps us make future decisions. In machine learning, it’s how we update the weights in our models to make better predictions. In human life, it allows us to gauge the effects of our future decisions by remembering what we’ve learned about the impact of our past decisions. Now, this can go either way. We can get feedback that encourages us to keep doing something, or we can also get feedback that encourages us to change something.

So here’s the tricky thing about feedback.

The point of feedback is to help a person or organization improve.

And from that perspective, we should look forward to it…right?

But a lot of times we don’t. Instead, feedback ends up producing a lot of anxiety in the workplace.

Why is that? Well, a couple of reasons. When we imagine receiving feedback, what we’re picturing is usually criticism. That happens because we focus more on negative feedback we receive that positive feedback. It also happens because, when we’re angry or frustrated with someone, we don’t have many options for expressing that in the workplace because it’s not considered professional etiquette to ever be angry or frustrated or sad or any of those pesky negative emotions. So we bubble up those negative emotions as feedback because that’s the only avenue into which we can shoehorn the airing of grievances.

That sets up a picture of feedback as you over on this side of the table [gesture toward a chair onstage, facing the left wall], and your goal over there [gesture toward the left wall], and the person giving feedback on the opposite side of the table as your adversary [sit in the other chair onstage, which is facing the first chair], blocking the way between you and your goal of getting your perfect score or your praise or promotion or bonus money.

When we’re seeing it like this, it’s scary to get feedback, because it’s scary to hear criticism.

And it’s scary to give feedback too. Because we get worried that maybe we’ll hurt someone, or maybe we’re even worried that the feedback recipient will retaliate against us.

Because we have this vision of the feedback giver and the feedback recipient on opposite sides of the table.

And conventional advice doesn’t shift that perspective…it just sort of tiptoes around it.

Giving Feedback

Conventional feedback advice:

“Constructive”: People say this (or sometimes “opportunity” feedback) to replace the term “negative,” but it doesn’t change the way anyone thinks about the feedback. Instead everyone back-translates this word to “negative” and the techniques doesn’t work.

💩 Sandwich: We sandwich a piece of negative feedback in between two pieces of positive feedback. Failure modes for this: People know about the sandwich and ignore the positive “bread” to focus only on the negative part, or people don’t know about the sandwich fail to understand the urgency of the feedback since it seems mostly positive.

Actionable, specific, kind: This is getting closer to a paradigm for how to deliver feedback, but it assumes that the feedback giver has control over whether their feedback is perceived as kind. And they don’t.

Why would the feedback giver not have control over whether their feedback is perceived as kind?

The recipient did not consent to this feedback, so its receipt was unwelcome.
The recipient doesn’t prioritize the skill that this feedback is about, so the receipt of this feedback feels like a request that they change their priorities.
The recipient was not expecting negative feedback and the receipt of this feedback was a surprise. This sometimes even happens when people ask for feedback—for example, when someone asks for “feedback” when the thing they really want is validation.

So if all this bad stuff is gonna happen to us, why give feedback at all?

To improve their work and your team: which affects your day-to-day at work,
To build a positive working relationship: which is great for your network and work experience,
To be seen as a mentor or adviser: a necessary part of assuming a leadership or expert role,
To get reciprocity for when you ask for feedback: so folks will help you out with feedback when you want to improve

How do we mitigate this risk?

I don’t give feedback unless explicitly asked.
I determine: does this person want feedback, or validation?

If they want validation and I tell them something is wrong, my feedback could be seen as unwelcome or unkind, even if I think they explicitly asked for it.

How do we determine whether, and where, somebody wants feedback?

First: I ask them for two or three goals that they have. This helps me understand: what are they trying to get better at, and therefore, in what areas might my feedback for them be welcome?

What might “Goals” mean in the context of a code review?

Usually when we write software, the main things we’re thinking about depend on the app and the project. Some options:

1. 1. Maintainability (legibility, flexibility)
  2. Documentation (tests, names, literal documentation)
  3. Resilience (to errors or inadvertent bad inputs)
  4. Security (against deliberate bad inputs)
  5. Speed

What might “Goals” mean outside the context of a code review?

Outside the context of a code review, colleagues might have all kinds of technical or interpersonal goals. For a while, for example, I had a goal of noticing when one of my less outspoken colleagues wanted to talk in a meeting, and helping them get the floor.

Second: I get the person’s self-assessment.

If it’s purely positive, they might be looking for validation. Which is sometimes fine, and I can provide it to build a relationship with this person. But I might not be safe to express any reservations in my feedback.

If, however, their self-assessment includes some concerns, it’s probably safer for me to provide something other than congratulatory comments.

For each goal, I make two lists:

Things they are doing that already max out their opportunity to be good at this thing (that is, things they should keep doing the way they are doing it to get closer to their goals)
Things where they still have additional opportunity to be good at the thing (that is, things they can change to get closer to their goals)

This moves the chair in the feedback conversation [move the chair facing to the right so both chairs are now facing toward the left] so both people are on the same side of the table, conspiring to help the feedback recipient get to those goals [gesture toward the left wall].

Receiving Feedback

When we’re thinking of feedback as this adversarial thing, giving feedback is scary, but receiving feedback is also scary.

We’re going to come back to the scary part, I promise, but first we need to talk about soliciting feedback.

Because we need feedback to get better. To accelerate our careers we want to absorb the knowledge and perspectives of other people, including about us specifically.

But in the working world where the peer reviews are not required, far more often than scary feedback, what we’re getting is no feedback, or insufficient feedback. And without it we can’t get better, so, how do we incentivize people to give us the feedback?

We expressly solicit it from people, rather than let it roll in. I find that if I gave someone thoughtful feedback in the past, they’re more eager to reciprocate when I’m looking for feedback. Even if the only feedback I’ve given them in the past is validating feedback, they tend to be quicker to give me whatever kind of feedback I’m looking for.

2. We give goals. This does several things for us:

Makes us safer to give feedback to: this signals that we want it enough to have thought about what kind we want.

Controls coworkers focus: so if we want technical feedback, we won’t get personality feedback.

Makes it easier to think of examples: as coworkers can filter their experiences with us to relevant occasions.

Makes it easier for folks to frame their feedback as an attempt to help: rather than unwelcome criticism.

3. After we receive the feedback, we follow the steps!

Thank them: this establishes that it’s safe to give us feedback—that we probably won’t retaliate.
Explain how we will act: so we get credit for responding to the feedback even before we have done anything.
Follow through: by using the feedback, we demonstrate to the giver that we value what they have to say.
Publicly praise the feedback giver for their help: so they receive a professional reward for helping us.

But what if it hurts? What if they have something bad to say?

When I was a coxswain, sometimes rowers would fill out anonymous evaluation forms about my performance. I hated it: I felt nervous every time. A few years in, I started reminding myself: people think what they think about you, so you might as well know what it is. By not asking them what they think, you’re not making them think more highly of you. You’re just cutting yourself off from the opportunity to fix it.

Having steps to follow in the event of tough feedback makes the feedback a little easier to receive, because it reduces the panic of not knowing what to do or say.
A night of sleep has prevented me from making many a rash decision. I tend to be able to distance myself and think about things a little more clearly after I have slept on them.
Research: When I get feedback, I look it up. Have others received this feedback? How common or rare is it? Who tends to get it, and why? How do they fix it?
Processing buddy: I’ll find someone who has more institutional power than me, so they can feel safe saying no when I ask them to do emotional work for me. Then, I see if they’d be willing to help me work through my feedback.

Conclusion

We talked about the adversarial model for feedback and where it comes from.

We talked about a more cooperative model for feedback.

We talked about how to ensure our own safety before giving feedback, and how to give useful feedback.

We also talked about how to attract feedback, how to respond to feedback, and how to turn the feedback that we need to change something into an actionable plan.

So here’s my closing salvo on why this topic is so important: not only do we know we need feedback, and theoretically want feedback…

…but also, feedback is the only mechanism by which we can access a perspective other than our own about our work. And that—capitalizing on perspectives other than our own—is exactly what leadership is. Without it, what we’re doing isn’t leadership; it’s acting alone, which is rarely successful and, I would argue, never sustainable. And no matter what field we’re in, or what role we play there, or what title we hold, if we do it long enough, we’ll eventually have to step up and lead something. My hope is that this talk provides you with some tools to take on that challenge with a lot less stress. Thank you.

End of Draft Transcript

If you want to see me deliver this at a stage near you, send this link to someone who can make it happen.

And if you like reading what I have to say about feedback and technical teamwork in general, you’re in luck.

Chelsea Troy