FeedBackTopic

Sometimes people learn from doing it right. But, there is something to Mike's suggestion that the mistakes stand out. I had an employee who did things right and I gave positive feedback at those times. After he worked with me about three years, he asked for feedback about what he did wrong that he could improve. - BeckyWinant 2-15-02

Regarding feedback, we need a sensible balance of positive & negative feedback. Too much positive promotes hubris, leading to delusions of perfection. Too much negative makes us pull into our shell and "comply". The Toastmaster's evaluation technique, the "sandwich" approach is a good model for providing quality feedback and having it stick. The sandwich is composed of 2 slices of positive feedback - what did I like, how have you shown growth, etc. The middle is the "meat" what one or two things could make the individual even more effective in the future. The reasoning on the sandwich: you pay attention after your need to be heard/understood is acknowledged (the initial positive feedback) and then you're in the mood to ask "What could I do to improve?". In the improvement suggestions, hold it to one or two things at most because we can't focus on fixing more than that at one time. If you have many things to suggest for improvement, prioritize - you can't get more than one or two at a time. Finally, end it on a positive note, letting them know you are aware and pleased with the progress since last time, or some other acknowledgement even if only agreeing that they tried something new. - BobLee 02/15/2002

I don't like the terms "positive" and "negative" for feedback. It's just information, and you can make of it what you will. - JerryWeinberg 2/17/02

Jerry, feelings are facts, so my use of + and - or "positive" and "negative" are lined up with "What do you do well that I/we would like to see more of" and "What could you work on to be even better". Mastery vs. Opportunity. The point is that people can't handle more than 1 or 2 "Opportunities" at a time. Try concentrating on more than one change in a gymnastics routine and you fall all over yourself. BobLee 2/18/02

Last fall I took the American Canoe Association White Water Kayak Instructor's training. As we completed our presentations, the instructor trainers would ask us what we thought we did well, and what we thought we could improve on. Then the other instructor candidates had their chance on the same two topics. Finally, the instructor trainers would make their comments in the same order. I've not heard of the "sandwich technique", but recognize it as the instructor trainers always ended on a "+" note. DonGray 02/18/02

Perhaps the difference discussed here from my note is that these are all forms of external feedback, including externalizing your own thoughts on the matter. For internal feedback, I tend to seek the specific when I clearly make mistakes, but also tend to skip the introspection when I seem to have succeeded. I certainly have seen that in many of the software companies I've worked for. "We built it. The customer bought it. We must have done it right, so don't confuse the issue by pointing out 'mistakes'."

Jerry's comment on feedback being just information, brought to mind a recent conversation I had with management over defect reporting. The manager was arguing that we testers should check out a new defect with the developers first, so as not to "embarass" them. I countered that that leads to developers' permission being necessary for the official report. I argued instead that defect reports should be destigmatized as just an official means of communications. The manager bought into that. I was surprised! MikeMelendez 020215

Thank you for the comment "tend to skip the introspection when I seem to have succeeded." I've been working on my journaling and this is a nice addition. DonGray 02/20/02

Mike, where I was working until recently we tried to keep the stigma off by using the terms anomaly or issue. I often don't know if the developer coded something wrong or if I misunderstood what the system should do. All I really know (assuming the system did not blow up and the screen did not include mis-spelled words) is that I did not get the result I expected. Sometimes, my expectations are wrong, especially when there is no detailed spec. This led to including questions, analysis puzzles and reminders for ourselves in the Issue Log. Later, I had developers ask me to record bugs that I found when I was browsing in Development in the Issue Log so they didn't get lost or forgotten. Previously, I would not have recorded those, as the code had not been released to Test. The relationship between the testers and the developers improved significantly.

SherryHeinze 24/02/02

I totally agree with Sherry on the use of "issue" or "anomaly." We're in the information business, not the blaming business. JerryWeinberg 24/02/02

Hmmm. Sherry makes a very good point... we don't always know immediately if the system behavior is incorrect or not what we expected in the absence of a spec. The word "issue" leaves it open until some determination is made. EstherDerby 02/25/02

And I with both of you. The term my company uses is "BURT". It does stand for "BUg Reporting Tool", but no one sees the word that way anymore. It is more often paired with "Ernie". I think that may be one reason why I was able to be convincing. Still, when more senior management keeps emphasizing that there are too many of "those" unresolved, it's not surprising that pressure builds to report fewer, no matter what we call them. BTW, my personal preference is "symptom" but I do like the term "anomaly". I also prefer "lessons learned" to the more common "postmortem", but then I know just enough Latin to be dangerous to myself. Pax. MikeMelendez 020225

Mike, What about the term "retrospective" for a look back to discover what went well and what lessons can be learned? EstherDerby 02/25/02

If you're doing iterative, introspection between iterations is mucho better than retrospective when it's all over. BobLee 02/25/02

I agree. There's nothing that says you have to wait til the last inning is over to do a retrospective. More is mo betta.

EstherDerby 02/25/02

So what about giving feedback when it's part of your job (a manager giving feedback a person on the team they lead)? How did you learn how to give feedback in a work context? What is the most difficult feedback experience you have had?

EstherDerby 02/27/02

The most difficult feedback for me has been telling someone "you're fired". Even when I have given people information about where they need to improve, I always feel sad to terminate any relationship where I thought there was potential.

On the other hand, having had such a moment in my career, it gave me one of the best opportunities I've had.

So, I can hope that I've offered the same to a few others.

-BeckyWinant 2/27/02

I agree, firing someone is hard, but it's not always harder than the alternative.

I used to work for a company where it was very rare for someone to be fired, especially once they were in management and could do real damage. The most common strategy was to re-org a department out from under someone and then eliminate their job, a process that could take *years.*

Training in "how to fire someone" (and how to hire someone) seems like it would be really valuable to people moving into a management role.

EstherDerby 02/28/02

Esther, I like the term "retrospective". I'm in negotiation with the development manager on the next project I'll be testing (the current is not yet complete). I have suggested monthly "lessons learned" and he had no immediate objection. I'll try calling it a retrospective next session and see what he thinks. MikeMelendez 020228

Mike, I was curious, if you had previous objections to doing any sort of feedback loop before.

What challenges do you and other face in doing such an activity? Time? Culture?? BeckyWinant 022802

Mike, My experience has been that people are more likely to create and integrate new knowledge (the "learned" part of "lessons learned") when they have a chance to see something that's a little outside their current conceptual frame, or see something in a different way... a pictoral time line of the project in stead of the project plan, for example.

I use a bunch of visual techniques and guide information flow to help support this happening. I've seen people make some really interesting and helpful connections just by seeing the "big picture" instead of concentrating on the part of the project they worked most closely on.

EstherDerby 02/28/02

Becky, I personally think retrospectives are important. How can you get better if you don't look for the opportunities? But then I'm a tester and believe my job is finding anomalies and reporting them. The most common objection I've heard when I propose a retrospective is, "We haven't got time for that." The second most common is the one I note above about the customer having bought the product. I half expect someone to quote Satchel Page when I suggest it.

From this feedback discussion, I think framing the retrospective is of critical importance. Esther's idea of a visual approach sounds particularly interesting. What I've tried in the distant past was asking the questions, "What do we want to keep doing? What do we want to change?" But that was in a company that was failing and many had more time than they knew what to do with, so getting a meeting together was easy. MikeMelendez 020301

"What do we want to keep doing? What do we want to change?" are great questions, but I think they are not the first questions. I start with "What did we do? How was it for us?" This can be very different depending on where you stand. This is what I build the visual record from -- and creating it from multiple points of view makes it possible for people to see a bigger picture. Then I start asking "What was happening here? What story does this tell?" The story leads to the answers to "What do we want to keep doing?" and "What would we do differently?"

I have digital photos from a couple of different retrospectives, and it's really interesting what show up in them. One group I worked with sat there for and hour and a half after I closed the day, just looking at the timeline and processing what had happened. It was a really powerful experience for these folks. If someone will give me instructions, I'll post some of the retrospective photos :-)

(I could go on a bit about retrospectives... I'll try to limit myself!)

EstherDerby 03/01/02

I agree that retrospectives really help to process the information. Plus, I am a HUGE fan of visual information. The time line that Esther talks about is very powerful. I can imagine her one group hanging around gazing at the information and comparing their experience at different points in time to those of others in the session. The time line shows the threads connecting the project member as well at the peaks, valleys and the story. If it was a success, where were the turning points? If it failed, where do crises and downward turns reflect that?

Visuals are rich with information.

I've done feedback sessions with affinity groupings, too. People post their biggest lesson learned, disappointments, critical turning points, and lots of other parameters appropriate to a project effort. The groupings form subjects for discussion. - BeckyWinant 3-01-2002

I am looking for sources and references on learning how to give feedback within a work context: manager-to-team member; manager-to-boss; peer-to-peer. Does have a book, article or other resource to recommend? (I've go "What Did You Say?" by Weinberg and Seashore covered.)

EstherDerby 030202

Esther: Fisher & Sharp in Getting It Done: How to Lead When You're not in charge devotes chapter 7 (27 pages) to learning how to use Feedback. BobLee 03/02/02

I noticed that when I expect a "feedback" I don't get one. However if I focused on getting a "response", bingo.. i will get one. Why is this so? I asked myself. CherDevey 23-Mar-2002

Cher, Hello! I was looking at the words and considered how they struck me. "Feedback" seems passive. "I'll sit back and wait for feedback". If none came perhaps whatever was asked sounded rhetorical or the feedback interpretted as optional.

"Response" comes in a pair with "stimulus". And stimulus is very active. It pokes and prods. Perhaps your words or questions were more stimulating or provokative when you "focused" on getting a response? - BeckyWinant 3/22/02

Yes, the response is feedback, too. Of course we get feedback in the form of responses everyday.

I was thinking of feedback in a more formal mechanism to negotiate relationship or performance. In Jerry's book, he says that feedback is about the sender, and I think this is true of responses, too.

EstherDerby 032402

Any response is a form of feedback, but intentional feedback, "What I thought when you..., what I felt when you..." is a higher-trust, richer response. It opens a window where otherwise we're forced to guess through observations filtered through our own preferences and biases. We can guess what the body language means, what the tone and content implies, but those are hints and clues rather than personalized opinions.

BobLee 03/24/02

Intentional feedback = focused response? Response requires not only the sender but also the receiver to provide the expected or required feedback. One is more congruent that the other ? Can a "mechanistic-type" feedback be make to deliver a "congruent response"?

CherDevey 28March2002

Intentional feedback is a focused response not the focused response. Responses all tell us about the sender - like x-rays through a crystal scattering onto a film tell us about a material sample. Some views are more informative and expose more hidden structural alignments. Honest intentional feedback may not require full congruence, but without congruence, it may be designed to inflict rather than to help. Example: "When you said XXX, I thought you {meant | implied | forgot} YYY" Helps map how I'm transforming XXX, so you can calibrate and reach me.

BobLee 3/29/02

My team is investigating retrospectives with the intention of trying a small one with the team from a small development project that is just completing. Can anyone point me to information on how frequently retrospectives are used in the computer industry? MikeMelendez 020411

Mike, try Software Assessments, Benchmarks and Best Practices by Capers Jones, 2000. You'll find a lot of project actual statistics classified by kind of software product. I'm not positive, but I think I recall percentages of retrospectives. It varied from System Software, Commercial, In-House, Military and Sub-Contracted. Good luck.

BobLee 2002.04.11

Mike -- I just spent some time with a group of people who have been doing retrospectives regularly for 5 years. The are seeing significant improvement over time. I don't think their data is public; I could ask if they are willing to correspond with you.

EstherDerby 04/12/02

Norm Kerth wrote the book on Retrospectives - does he have any statistics you can use?

BobLee 2002.04.12
[Contact Norm at [email protected]]

Thanks, Esther and Bob, In fact, I am reading Norm Kerth's book for ideas and partly as a result of our earlier discussion of postmortems, lesson learned, and (new name to me) retrospectives. JohannaRothman had recommended it. I haven't encountered any statistics but it's not that kind of book as Capers Jones is. I now have the Assessments book and begun sampling it. The main statistic he seems to use (I've barely started) at the individual practice level is a threshhold statistic. The particular practice threshhold is use at 10 companies and 50 projects. Of interest in my effort so far was a developer (whom I greatly respect) that suggested our company was too small, that retrospectives were done by big ones like HP and IBM.

Esther, If the group you're working with is willing, contact with them might be very useful, particularly if they're willing to talk directly to management here, but useful even if they ask me to protect their anonymity. I worked at several companies where such success would be considered a business secret.

MikeMelendez 020415

Funny how "business secrets" work. Remember how everything in the government routinely got stamped "Top Secret" to avoid embarassing audit? There's a strong tendency for Command & Control folks to play the "need to know" game. This has the distressing tendency to retard progress big time.

BobLee 2002.04.15

Mike, I've worked with small and large companies doing retrospectives. The smallest was probably 30 people in the entire company.

Sometimes its faster to effect change in a small company -- there are fewer organizational buffering forces to content with, so a small shift can have a bigger effect.

I'll contact the 5-year group to see if they are willing to chat.

EstherDerby 041602

Updated: Tuesday, April 16, 2002