Giving and receiving feedback: Constructive in the team

In short: Good feedback concretely describes observations, names the effect and makes suggestions; receiving feedback means listening, asking and deciding yourself what to change.

In more detail: In training, projects and teams one learns through feedback. Bad feedback (“That was bad”) hurts, good feedback helps you move forward.

In Depth

Giving feedback

A proven pattern: situation – behaviour – impact – wish (SBI/SBIW):

1. Situation: “In yesterday’s customer meeting …”
2. Observation (without judgement): “… you summarised the requirements after only five minutes.”
3. Impact: “That helped the customer to understand the situation.” / “I felt overridden.”
4. Suggestion/wish: “Next time please ask briefly beforehand.” Add I-messages, concrete examples, promptly, in private for criticism, praise publicly; balance positives and improvements. Do not judge persons (“you are unreliable”), describe behaviour.

Receiving feedback

• Listen, do not interrupt, do not justify immediately.
• Ask: “Can you give an example?”, “What would have been better?”
• Thank: feedback is a gift, even if unpleasant.
• Let it sink in and check yourself what is true. You decide what you implement.
• Do not take it personally: it is about behaviour and result, not your worth.
• Feedback heard repeatedly is especially valuable.

In everyday training

Actively ask for feedback: “What can I do better?”, “What went well?” (for example after a project, presentations, exam preparation). Regular talks with the trainer (monthly) and reflection in the training record (what did I learn, what do I take with me?). Code reviews and retrospectives are feedback formats in the team. If you give feedback to older people/superiors, stay respectful and concrete.

Difficult cases

• Unfair feedback: ask for concrete examples, contradict calmly, in a dispute involve a third person (youth representation, training management).
• Bullying/belittling is not feedback: document, get help.
• Cultural differences: directness varies.
• Written feedback is harder to interpret: when in doubt talk.
• Your own feedback: note responses and check how they change your actions.

See also: Code review, Training record, Scrum in practice