My name is Chelsea Troy. I write code for money. I teach programming at the University of Chicago, also for money.
I also write about tech and live stream my open source programming. Neither of those is strictly for money.
I organize a local, one day, single track, lightning talk conference about the joy of computing. It’s called PromptConf. If that sounds cool to you, find me after.
Today, I thought about live coding an ambiguous evaluator into a Scheme interpreter with you. But that seemed a little heavy for an afternoon talk.
So instead, I’m going to give you a masterclass in feedback that will help you excel at leading technical teams.
First, let’s establish what we mean by feedback. What is feedback?
- A signal
- from external sources
- about past decisions
- that informs future decisions.
A signal: There’s information in it. As opposed to noise, which doesn’t have information.
From external sources: This isn’t our self-assessment, which can be biased and can have blind spots. This is supplementary signal from our test output, our system logs, or another person. We’re focused on the person kind today.
About past decisions: This isn’t personal, though sometimes it feels that way. It’s about decisions we have made that resulted in this signal we’re getting.
That informs future decisions: Feedback helps us make future decisions. In machine learning, we update the weights in our models to make better predictions. In life, we gauge the effects of our future decisions by remembering what we’ve learned about the impact of our past decisions. 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.
When we imagine receiving feedback, we’re usually picturing criticism. We focus more on negative feedback we receive that positive feedback.
Also, when we’re angry or frustrated, 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. So we bubble up those 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, and your goal over there, and the person giving feedback on the opposite side of the table as your adversary, 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.
And it’s scary to give feedback too. Because we worry that we’ll hurt someone, or that the recipient will retaliate against us.
We have this vision of the feedback giver and recipient on opposite sides of the table.
And conventional advice doesn’t shift that perspective…it tiptoes around it.
What’s the conventional feedback advice?
“Constructive”: People replace the term “negative” with “constructive'” or “opportunity” feedback. But it doesn’t change the way anyone thinks; we just back-translate the word to “negative” and the technique 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.
- 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 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
If we want the benefits of feedback, how do we mitigate the 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. This helps me understand: what are they trying to get better at, so in what areas might my feedback 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:
- Maintainability (legibility, flexibility)
- Documentation (tests, names, literal documentation)
- Resilience (to errors or inadvertent bad inputs)
- Security (against deliberate bad inputs)
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, thinks they should keep doing to get closer to their goals)
- Things where they still have additional opportunity to be good at the thing (that is, thinks they can change to get closer to their goals)
This moves the chair in the feedback conversation so both people are on the same side of the table, conspiring to help the feedback recipient get to those goals.
When we’re thinking of feedback as adversarial, giving feedback is scary. Receiving feedback is also scary.
We’re going to come back to the scary part, but first we need to talk about soliciting feedback.
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.
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 can distance myself and think about things 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.
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.