Looking for feedback at the end of a project, as part of a development or at the end of a course, is something that isn’t yet common practice. In fact, a lot of people shy away from this kind of up-close and personal review of how well or how bad you have performed on the occasion. Probably out of fear of receiving bad feedback and making yourself vulnerable. In the words of one of my coaches: “Feedback is the breakfast of champions”
The thing about feedback is that it also provides amazing learning and improvement opportunities. In a learning culture where continuous improvement is core to the work environment, inviting and accepting feedback is important for the culture to work. Feedback can also be what can crush a persons’ confidence. Especially if the feedback resembled an attack on their person or questions their skills as opposed to feedback on a process or a task. We all master some things very well and others are learning opportunities, this doesn’t mean we are incapable of getting it right ever.
Giving meaningful feedback is a skill, not everyone masters. Comments like “good job” or “it isn’t working”, whilst they can be classed as feedback, they are also not useful to change anything. They are too vague and non-specific. I often give feedback on the gamification design tips my team selects from blog posts, often it may say something like “this statement doesn’t work without the context of the article, either provide context or pick a new statement”. Very often, the feedback there is simply: “I approve the following statements.” Those can be actioned.
Choosing your timing can also impact both positively or negatively on performance. You wouldn’t break down someone’s presentation style in a final rehearsal, you would do that in an early run-through, so the person has ample time to practise or review how they present. After the facts, I would suggest that you look for permission to give feedback and then proceed or respond when invited. In a feedback culture, it should, in my opinion, be acceptable to refuse feedback in the moment, but then re-visit it when you are ready. We all have times where we are more open to feedback than others. But we can’t always control the feedback givers’ timing and in some cases, it comes on the spur of the moment and you have to weigh up how and when to deal with it.
The intention is another factor that can impact feedback and in most organisations even smaller ones, politics and people dynamics may cause certain feedback. I believe if you give feedback to genuinely improve a project outcome, then it makes sense to volunteer it. If for example, you feel a fear of losing your job or role being taken or you simply dislike a person or organisation, then always verify your true intentions as a feedback giver. If the intention is not for the higher purpose of improving the project, then let it go, scribble it in your personal notes somewhere, but don’t share it.
In the world of iterative design and development, feedback is a way to improve what is worked on. For it to work, all parties need to be aware of the iterative nature of the way work will take place as well as a constructive feedback mindset. Swooping statements such as “it is not up to standards” without an example as to what standard and where it goes wrong is unhelpful and obstructive in iterative design. Constructive feedback should then also allow for a right to reply and a right to rectify. Sometimes the feedback is very valid and you just need to implement changes. Other times feedback can come and there may be very good reasons, why something has been developed a certain way, in which case an explanation of methodology is in order.
Although it isn’t always easy to handle feedback, especially when negative, it does provide an opportunity to do better. Right first time in our work is simply an illusion. Feedback is what makes our projects and work better.
