Contents:
- This month's Feature Article: Providing Effective Correcting and Reinforcing Feedback
- Announcements
=-=-=-=-=-
Feature Article: Providing Effective Correcting and Reinforcing Feedback
So you can't stand the way Bonzo checks in his broken code on Friday afternoons. Or, Cecile has such bad breath no one wants to work with her. Or, you're not sure how to tell Dougie he wrote such a great report. Welcome to correcting and reinforcing feedback.
In Behind Closed Doors: Secrets of Great Management, Esther and I explained a recipe for effective feedback:
* Create an opening to deliver feedback.
* Describe the behavior or result in a way the person can hear.
* State the impact using “I” language.
* Make a request for changed behavior.
Here's how it might look when you have a trusting relationship with the other person.
“Bonzo, got a minute?”
“Not really, I'm rushing out the door–it is Friday afternoon you know.”
“Well, ok, but that's what I wanted to talk to you about. I can wait until Monday morning if you want.”
“Well, ok. What's up?”
“Are you aware that your most recent checkins, the ones from half an hour ago, broke the build?”
“Ah, nuts. I thought I took care of those problems.”
“Well, they did. And when your code breaks the build at 4:30 on a Friday afternoon, someone's got to fix the problem, or back out your code, or everyone lives with it until Monday. Since we're working across a bunch of time zones, I don't want everyone to have to live with it until Monday. It's hard for me to know what the real state of the project is when the build's broken. And, it's hard for the rest of the project team to perform continuous integration with broken code and you're gone.”
“I can see your point.”
“I'd like to work with you on this on Monday. I bet we can figure out a bunch of ways to fix this problem. OK?”
“OK.”
If I didn't have a good relationship with Bonzo, I might not approach him on Friday afternoon as he was walking out the door. But notice, I didn't tell him he was an idiot, or that he “always” did this “bone-headed” thing. Useful feedback doesn't label people, nor is it a general statement, nor does it use derogatory terms to describe behavior. Useful feedback is specific, close to the event, and in the case of corrective feedback, asks for problem solving or a change in behavior.
Reinforcing feedback follows the same recipe:
“Dougie, before we start our one-on-one, I want to let you know about your report. I loved it. Here's why: I found the table of contents useful. I like the summary at the front–and so did the VP. Your writing was persuasive and clear. I understood the problem and your solution. That's why you did a great job on the report.”
I sometimes practice what I'm going to say, especially if I think the conversation will be difficult. But providing effective feedback is a necessary tool for anyone working with other people–especially managers or leaders.
=-=-=-=-=-
Announcements
I've redesigned my web site, so if you haven't visited in a while, take a look: <https://www.jrothman.com>. And, I've finally updated my calendar page: <https://www.jrothman.com/calendar.html>. I'm leading 5 sessions at Software Development Best Practices in September and hope to see you there.
Our July Managing One-on-One workshop was a success. Esther and I will be choosing our 2007 dates shortly.
We've posted the schedule for 2006 AYE conference (Nov. 5-8, 2006) in Phoenix, AZ. See <http://www.ayeconference.com> for more details. If you're not on that mailing list, you can either sign up on the AYE site, or send me an email to add you.
As always, take a look at my blogs to see my most recent writing: Managing Product Development and Hiring Technical People.
© 2006 Johanna Rothman
If you'd like some common sense, down-to-earth ideas about how to manage your projects, manage your people, or manage your individual work, you've come to the right place.
See back issues of my email newsletter here.
Tell me how you've used these ideas. Or, if you have questions, comments, or feedback, tell me that too.