In the last couple of years, I have noticed two very different kinds of feedback. One is plain and simple, mostly driven by policy, because feedback is expected to be given. It gets documented, acknowledged, and then quietly forgotten. The second kind is more detailed and thoughtful. I receive it far less often, but it is the kind I try to give whenever possible.
Based on these experiences, I ended up with a simple acronym for myself using the F-E-E-D-B-A-C-K, mainly to keep feedback focused, clear, and useful rather than vague or checkbox-driven.
F —Facts over feelings
E- Empathy for context
E-Expectations made explicit
D-Data-backed assessment
B-Behavior-focused, not personality-based
A-Actionable next steps
C-Continuous, not episodic
K-Knowledge-oriented outcome
I am curious to know how others approach this. What is your preferred way of giving feedback to your teams? And in what format do you personally find feedback most helpful when receiving it?
There are few things which i take care of when i’m giving feedbacks.
It has to be constructive. The other person should be able to take something out of it
The written feedback should never be a surprise. The other person should have known verablly or in some way about this before, so that written should be considered something serious
Whenever given there should be time for other person to consume it, so i give them around weekends.
I divide the feedback in sections like Strengths, Weaknesses, Needs Improvements or some similar structure in a way that the pointers are sandwiched and it doesn’t get overwhelming for the other person
Negative things should be shared with example.
At the end of feedback, make yourself approachable so that other person finds a room for discussion.
Similar to this what i look for when i look for recieving feedback. Specifically, i go with questions i need answers of which i get in form of feedback which i can use.
From the training on this I have received, it does reflect your little acronym @ujjwal.singh . Good managers give good (well structured) feedback. That is all I can authoatively say about giving it. I’m not a people person, 90% of software engineers are “on the spectrum” and are going to be rather poor at giving feedback without people-skill training. . We have an “kudos” social type platform at work where we can recognise good work done by others, and I have started to engage with this as a way of letting managers know when their team members do good work to help me. I’m aware that bad feedback has to be done “sandwich” style. And bad managers don’t do this. Hence why I exited my last role. Speak only of the good, and let the bad die of neglect. (MAT15:4)
Many people who have insecurities, will go into panic mode even when feedback is positive, I’m one of them. As such I like my feedback regularly.