Uncharted Waters

Jul 20 2016   1:29PM GMT

Surprising Secrets of Giving Feedback

Matt Heusser Matt Heusser Profile: Matt Heusser


supervisionLast month, my colleague, Justin Rohrman, posted a piece on giving feedback here. Justin’s suggestion was the “Sandwich method.” The sandwich starts with a positive mention, then the thing that really needs to change, then ending on a positive note.

That might work for getting people to change behavior, but it’s terrible for supervision.

A few years ago I received a feedback sandwich. It went like this: Thank you very much for your work on projectX, by the way, this behavior is terrible and needs to change, gosh it is great having you on the team.

Think about the stress I went through in that moment. Am I doing well? Am I getting reprimanded? Is this the first step toward a written reprimand? I don’t know. I left the room more confused than when I walked in.  That verbal message was on the way to my first and only written reprimand as an employee.

The sandwich is certainly a way to give feedback, it can work in some circumstances, and having more ways to do it is better.

Today I’d like to provide you yet another option: The Spot Correction.

Immediate Feedback

Imagine you are sitting in a room with your supervisor and the customer. As you walk out to get back to your office, he turns to you “Remember when the client made that outrageous demand for an estimate?”, you reply “yeah, that was crazy!” The you get the feedback “Look, I know there is no way we could have the work done by October first. But the customer clearly wasn’t ready to hear that. Also, the work wasn’t even defined well enough for us to give them an estimate.”

Again, you nod your head. That was obvious. Now the supervisor connects the dots.

“If you say no, you’ve rejected the client. You’ve essentially called them stupid, because really, they should know better. Also, saying it would be ‘too hard’ takes the decision away from them. Instead of saying no, next time, just ask for details. When they don’t have the details, ask to get back to them. Build them three different choices for features, along with duration. You’ve got to let the customer own the decision. Do you know what I’m saying?”

Odds are, you’ll be taking notes.

Contrast that to the manager trying to make his own notes up, including two good points (to do the sandwich) and delivering it next week at your one-on-one meeting. It’s likely you won’t remember what happened in the meeting, you’ll resent the feedback, and be more a bit offended by the Monday-Morning-Quarterbacking.

Sure, it’s easy to have a better idea a week later, but why didn’t the supervisor correct in the meeting, or right after? Because he didn’t think of it either, right?

Those are the kinds of thoughts that go through the head with a “well planned” feedback session. Wait for a written reprimand, or an annual review, and things will only get worse. At one review, I got a fails to meet expectations in one area. I asked my supervisor if those expectations had ever been clearly set – and – when he said no, he adjusted the score to “meets.” No one left that room happy.

Spot corrections, though, have a problem. There is a reason they don’t happen often enough.

The Supervisor Needs To Be There

pairingConsider the supervisor is pairing with a programmer. Fifteen minutes into the work, the supervisor points out there are a lot of if statements in three variables. It looks like the business rules will keep changing, requiring more code changes. Instead of conditionals, he suggests letting a database table drive the behavior instead. After all, tables are much easier to insert rows into than code changes.” The programmer replies that he doesn’t quite know how, and the supervisor replies “Let me show you.”

Problem solved in fifteen minutes.

Now imagine the supervisor is absent. The issue comes up in code review which means rework. Or it might come up in some form of formal feedback process, meaning more rework without clarity on where the time will come to make the changes. Worst of all, the programmer doesn’t really know how to do it, will be unlikely to ask for help.

The difference is the power of spot corrections, but it doesn’t happen enough. In our culture of “hit the ground running” and “baptism by fire”, leaders and managers seem to be too busy to, well, lead and manage. This is a serious cultural problem, which results in shoddy work that doesn’t get better.

Yet despite fifteen years of Agile Software Development and nearly twenty of Extreme Programming, pairing is probably single most culturally rejected element of Agile Software Development.

I am tempted to this in my own work — to skip that meeting, to let someone else handle it, to let go to focus on other things. Sometimes, that makes sense; no supervisor can give 100% of their time to even one person, and most supervisors have to manage more than one person.

The Bottom Line

If you want to improve someone else’s behavior, spend an hour or more a week actually working with them on the task at hand. You might learn that task is more complex than you realized. If you are being supervised, and getting strange feedback late from your leaders (Imagine the client in the first example called the boss because he wasn’t there), then invite them to work through a problem with you for an hour or two a week. They’ll likely be flattered.

Of course this works on peers, on juniors and seniors as well. As a junior, when you get help, that is actual mentoring and coaching – not just coffee a few times and a checkbox on a review sheet.

As for the objections to pairing, and getting over them … let’s keep talking. In the mean time, I’d like to know what you think.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: