Esther Derby writes great advice on giving feedback. I’m intrigued by her closing comment:
I think it depends on how a feedback sandwich is used. I tend to use it to make a safe space in which I can share feedback with people without them feeling like the world’s just been cut out from underneath them. I find it helps me phrase feedback in a very positive, constructive manner.
This is not, to me, the most effective feedback sandwich, despite adhering to any rules I might previously have given:
So, here’s how I’m using the feedback sandwich now (all other rules of giving effective feedback also apply).
I value this…
Whenever someone gives me some advice or criticism, it makes me want to change things so that I’m more effective, or so that the problem is fixed.
For instance, a graphic designer gave me some feedback on my new business cards. “You need to revisit the whole card,” he told me. “Change the shape, add some texture. Put in a tag line, something catchy that people can remember you by.”
Well, I’m not a graphical artist! Nor am I pretending to be, so the feedback didn’t really get me down. I knew I couldn’t get new business cards ready in time for the conference, nor can I really afford the services of a graphical artist right now. I thought to myself, “I could just give out my email address; that’s worked for me before. I don’t really need to take my business cards to the conference.”
Then it occurred to me much later that perhaps that wasn’t the artist’s intention. So I asked him: “Would it be better for me not to take the cards at all?”
“Oh, no! That’s not what I meant. They’re fine, I mean, they’ll do the job if that’s what you want. I just wanted to give you some help to improve them.”
“Fantastic!” I smiled. “So, what do you like about them?”
“I like the colour scheme, and the symbol you’ve chosen – the big red moon – is very powerful.” And then he described the things he liked about the card.
Without anchoring the things that I value, I am in danger of losing them altogether. If I bring up someone’s annoying behaviour when they pair program with me, they might just stop pair programming. If I suggest a different way of solving a problem, they might stop thinking of themselves as problem-solvers. The human mind has this dangerous way of abstracting generalisations from particular situations, and confidence can be easily knocked! Even in the situation with the business cards, where I didn’t really feel depressed by the feedback, I was in danger of throwing away valuable work.
So, I can anchor the things I value; things that might change as a result of what I’m about to say.
“I love the solution you’ve come up with.”
“I really like the colour scheme and the icon.”
And…
The next bit of the “feedback sandwich” is the trickiest. It’s always tempting to put the word “but” or “however” in here! The word “but” has the impact of negating the first part of the sentence. I’ve heard this example a lot:
Mum: Well, he’s ugly, but he’s rich.
Daughter: Yes, Mum. He’s rich, but he’s ugly.
See what I mean?
Even the act of thinking “but” tends to lead me to phrase it unconsciously. So I’ve been trying to replace it with the word “and”. Like “should” in BDD, this leads my brain to go a different way. Instead of thinking of how to phrase the negative advice in a way which is palatable, I find myself phrasing things very differently.
“I love the way you’ve solved this problem, and I’d like to build on that.”
“I love the colour scheme and the icon, and I think there may be some ways of making them stand out.”
This has led me to new ways of providing feedback. I can even talk to managers now!
I don’t always need to criticise the behaviour that’s causing me problems in order to suggest changing it. Thinking about the last part of the feedback sandwich, and using that to work out what goes after the “and…”, helps me work out what to say.
…I want this.
There’s some place that I want to get to; some goal that I want to achieve. NLP’s well-formed outcomes can help here, or if you’re a software developer, think about the SMART technique for writing tests. How will you know that you’ve got to the place that you want to be in? What will you see? What will you hear? What will you be doing – or not doing – differently?
“I love the colour scheme and the icon, and I think there may be some ways of making them stand out. Perhaps if we had something textured, or cut into a different shape, that would catch people’s attention.”
“I love the way you’ve solved this problem, and I’d like to build on that. Maybe we could assign responsibility for this bit of the code to another class. I think that would make this class simpler, and then we could write some tests to describe its behaviour so that other people could use it too.”
“Thank you very much for letting us try out this Agile stuff! It’s great; I’m having fun. I really like the lightweight documentation, and I’d like to try and work out how to align that aspect of it with the reports you asked me for. Can you help me? I’m looking for a way to try and use the data that’s up on the walls and the project board to make this easier.”
Even when there’s some particular unpalatable behaviour that really does need to stop, this can help.
Even when it’s really unpalatable behaviour.
Provide options
I like the feedback sandwich because it sits very well with GROW, in which we move to our Goal from our Reality, looking at Options and selecting a Way Forward. Reality is the current behaviour that we value (not the problem!) and the Goal is where we want to get to.
In the examples of feedback I’ve given above, I’ve provided multiple options, or left an opening for them. Even when there’s only one option that can realistically be taken – nobody’s going to say “no” when I ask for more time to type code without having a back-seat driver telling me what to do – I’ve phrased it in a way which makes the other option available. Using words like “maybe”, or asking questions like “What do you think? Can you help me?” can invite other options, things that we haven’t thought of.
There’s safety in these options. By providing them, and allowing the coachee to make the choice, we’re saying, “You have the power here. You get to make the choices.” All I’m doing is sharing a place that I want to get to with you, and leaving it up to you to decide how to get there. You can ask me for help if you want, and even give me feedback if there’s something that I can do that might make a difference.
I was reading this article which starts with an assertion, “old commented-out code is an abomination”. That makes me wince, because an abomination is something hateful, wicked or shamefully vile, and what I see is someone learning! That’s not vile at all; it’s a wonderful thing, and I heartily encourage it. Instead of insisting that the code is deleted, I might suggest trying it out, and seeing which one works best. I might even talk about the benefits of deleting the code. Creating it as an option, instead of “the only right way”, will allow Alphonse to feel safe trying out other things, too.
(Incidentally, the way that the feedback is given in the scenario with Alphonse isn’t very safe. Giving feedback in private is usually better than giving it in public.)
Big thanks to Chris Matts and Real Options for helping me see the similarities between GROW and the sandwich model, and fitting Options into it. I’ve found it’s worth paying to create Options, and I might sacrifice some related feedback I want to give, or my idea of “the right way to solve it”, in order to do so. This has been very effective, and I find it a very natural way of giving feedback now.
Why don’t you give it a try?
I hate blame cultures. If you hate them too, then you don’t need me to tell you why. If you don’t, you probably haven’t worked in one yet.
At one client, they have a strong dislike for blame cultures. Unfortunately, most of the development team have worked in one at some point or another, and it’s hard to get out of certain habits.
“Ah, it’s all right,” one developer said, looking at a bug. “It’s not our fault.”
“I’ve been learning a bit of NLP,” I said, “and it suggests that the words we use can sometimes affect the way we think. I know that you’re not really thinking about blame when you use those words. Even so, can we avoid them? Could you maybe ask the question, Who’s the best person to fix this? instead of Whose fault is it?”
“All right. I’m still not the best person to fix this, though.”
“Well, who is?”
“I think George broke the build. I mean, George is the best person to fix it.” The developer called across, “George, can you look at the build a sec and see if you could fix it, please?”
“Oops!” said George. “I’m on it.”
So he fixed the build, and the team started working. A while later, one of the QAs called me over. “Liz, I’m looking at this bug… did your team cause it?”
I shook my head. “It looks like the database might be down.”
“Oh,” the QA said sadly. “I can’t blame you, then.”
I winced. “Why do you need to know whose fault it was?” I asked.
“So I know who to assign it to.”
So I explained about the new words we were trying to use instead of “blame” and “fault”.
“Oh!” she brightened up. “Well, are you able to help me fix it, then?”
“Maybe one of my team can help. Hold on!” So I asked around. “Who’s the best person to kick Mary’s database? It looks as if it’s fallen over.”
“I can do that!” Fred announced.
It occurred to me at that point that, if we were still asking, “Whose fault is this?” then Fred would be reluctant to help out, because it would insinuate that it was somehow his fault. By avoiding the words and asking, “Who’s the best person to fix this?” anyone can volunteer.
Suddenly, by providing an alternative to “fault” and “blame”, we’ve made it OK for people to volunteer to contribute. That can only be a good thing.
Comments