Today I was confronted heavily on many aspects of some tools (which I will mention as "ToolX") I have implemented. I will put this as "feedback" as calling it "critics" is limiting (it was not all disruptive but also constructive).
Anyway; the sense of it is simple : getting feedback is easy; taking it is hard.
The first reaction to feedback is usually very well described by the following situation:
You sit at work, a co-worker comes up to you.
Out of the frequency this event happens, you can give a score to the value of your work. This is why it is important to not just say the following :
Which, translated into practical sense, equals to NOT listening.
An answer like the following:
So this seems easy so far - unless you have attitude problems (like myself); but then it's bad luck and failure until you learn your lesson (which might take some time, I tell you).
So, assuming your colleague did not run away chasen by you, the next thing you will have to figure out what is wrong with ToolX. Is it working? Yes/No? If no, what is the cause? Your colleagues wrong usage of the tool? a bug in it? environmental conditions (for example file shares offline...)?
In the end, alot of issues to go through. Assuming there was actually an issue - either in the user's usage or in the tool / environment required by the tool to run, the result might be :
What I want to focus on, is the magic moments of the conversation in which you will get negative feedback on ToolX. Why? It is easier to put it in a metaphor:
a feedback collection (from your point of view) is a race that your tool is being putted into, to evaluate it's performance. If the tool fails to achieve the race's goal (which it probably already did, for an example in the situation given above) or completes the race poorly (which means the User's list of bad feedback is LONG), your tool is most likely not up to the task
This reality might hit you; but also, you might not even hear it, because your self-protection mechanism will automatically switch the areas in charge of common sense of the brain off.
So the reaction can be two fold, either you listen and do not take action (because you did not really listen to the feedback), which I will herein call SCENARIO#1, or you take the reality: you have a shitty tool and do something about it, which is SCENARIO#2.
So far for the consequences. But how to be able to decide which of the two abovementioned outcomes to go? In the case of SCENARIO#1, you are obviously not in control of yourself anymore (at least not directly), because you will simply ignore the input from the User. Do not get me wrong, you will still hear it; but it will go through your ear (in through one and out from the other) like air.
The solution is being able to recognize when your brain shuts down.
Whenever you get feedback, ask yourself:
- how many questions about the feedback have I asked?
- how many valid feedback points (out of the ones mentioned by the User) have I collected?
- how much chance for feedback have I given to the User?
I think the most tricky being the third one:
Usually, on negative feedback we react with defensive walls or "counterattacks" like
The more of these whe shout out, the less feedback we have collected, the more we are sliding in SCENARIO#1.
Any of these "counterattack" reduce the chances of feedback for the User, for various reasons.
It makes absolutely sense to let the User speak. Even if his thoughts are nonsense, let the User speak.
You can decide later on what to do with it (provided you remember it).
I think this could be a good reminder for myself. Feel free to use it for you too, if you think it might help :).
Anyway; the sense of it is simple : getting feedback is easy; taking it is hard.
The first reaction to feedback is usually very well described by the following situation:
You sit at work, a co-worker comes up to you.
"Hey xx, I have a problem with tool xx. It does not do it's job."I am pretty sure that this situation hits (or has hitted) alot of us.
Out of the frequency this event happens, you can give a score to the value of your work. This is why it is important to not just say the following :
"What? Impossible, my tool xx is awesome and works!"or
"You must have used it wrong!"
Which, translated into practical sense, equals to NOT listening.
An answer like the following:
"What is the issue?"or
"What's the matter?"would probably be more appropriated.
So this seems easy so far - unless you have attitude problems (like myself); but then it's bad luck and failure until you learn your lesson (which might take some time, I tell you).
So, assuming your colleague did not run away chasen by you, the next thing you will have to figure out what is wrong with ToolX. Is it working? Yes/No? If no, what is the cause? Your colleagues wrong usage of the tool? a bug in it? environmental conditions (for example file shares offline...)?
In the end, alot of issues to go through. Assuming there was actually an issue - either in the user's usage or in the tool / environment required by the tool to run, the result might be :
"Ah, I did not know I had to do it like this"or
"Ah, there is a bug!"or
"F*ck, why is this server offline?"Anyway, the outcome can be various.Usually if a bug is found, a discussion about the tool might emerge, and if the galaxy stars happen to be in the right configuration, you might be as well as lucky as being able to collect some feedback on ToolX. The form of this collection is purely passive; meaning the User will give a (usually oral) list of issues that he / she has encountered during his/her life making use of ToolX. See, here is the first challenge: Organizing feedback transfer. But let's not focus about that, there is plenty of documentation on the topic already.
What I want to focus on, is the magic moments of the conversation in which you will get negative feedback on ToolX. Why? It is easier to put it in a metaphor:
a feedback collection (from your point of view) is a race that your tool is being putted into, to evaluate it's performance. If the tool fails to achieve the race's goal (which it probably already did, for an example in the situation given above) or completes the race poorly (which means the User's list of bad feedback is LONG), your tool is most likely not up to the task
This reality might hit you; but also, you might not even hear it, because your self-protection mechanism will automatically switch the areas in charge of common sense of the brain off.
So the reaction can be two fold, either you listen and do not take action (because you did not really listen to the feedback), which I will herein call SCENARIO#1, or you take the reality: you have a shitty tool and do something about it, which is SCENARIO#2.
So far for the consequences. But how to be able to decide which of the two abovementioned outcomes to go? In the case of SCENARIO#1, you are obviously not in control of yourself anymore (at least not directly), because you will simply ignore the input from the User. Do not get me wrong, you will still hear it; but it will go through your ear (in through one and out from the other) like air.
The solution is being able to recognize when your brain shuts down.
Whenever you get feedback, ask yourself:
- how many questions about the feedback have I asked?
- how many valid feedback points (out of the ones mentioned by the User) have I collected?
- how much chance for feedback have I given to the User?
I think the most tricky being the third one:
Usually, on negative feedback we react with defensive walls or "counterattacks" like
"No you did it wrong"or
"No the server was down"or even
"You do not know what you are talking about"and on.
The more of these whe shout out, the less feedback we have collected, the more we are sliding in SCENARIO#1.
Any of these "counterattack" reduce the chances of feedback for the User, for various reasons.
It makes absolutely sense to let the User speak. Even if his thoughts are nonsense, let the User speak.
You can decide later on what to do with it (provided you remember it).
I think this could be a good reminder for myself. Feel free to use it for you too, if you think it might help :).
No comments:
Post a Comment