Giving and receiving feedback

Why it matters

Feedback is how people and teams improve. Code reviews, design critiques, lab audits, performance check-ins and quick "can I tell you something?" chats are all feedback. Early in your career you will receive far more feedback than you give, and how you handle it shapes how fast you grow. You will also need to give feedback to peers, and doing it clearly and kindly is a skill most people never learn properly.

Why feedback goes wrong

Most bad feedback falls into one of two traps:

• Too vague. "Great job!" or "That presentation was a bit off." The person does not know what to repeat or what to change.
• Aimed at the person, not the behaviour. "You're careless" or "You're not a team player." This feels like an attack, and people defend themselves instead of listening.

The core idea: Situation, Behaviour, Impact

The Situation-Behaviour-Impact (SBI) model, developed by the Center for Creative Leadership, avoids both traps. You describe three things:

1. Situation: when and where it happened. Be specific. "In Tuesday's client call..."
2. Behaviour: what the person actually did or said, as a camera would record it. No guesses about their motives or character. "...you explained the outage timeline step by step and showed the graph..."
3. Impact: the effect it had on you, the team, the work or the customer. "...and the client said it was the first time they understood what went wrong."

Because the behaviour is observable, the other person can accept it as fact. Because the impact is about effects, not judgement, it explains why it matters.

After SBI, you can open a conversation: ask a question or suggest a next step.

Worked example 1: positive feedback

Vague: "Nice work on the docs."

SBI:

Situation: When I set up the project on my new laptop yesterday,
Behaviour: I followed your setup guide, and every step had the
           command plus what I should see after it.
Impact:    I was running in 20 minutes instead of the half day it
           usually takes, and I didn't have to interrupt anyone.

Specific praise tells people what to keep doing. It is worth giving often.

Worked example 2: constructive feedback

Judgemental: "You always ignore the review process."

SBI, followed by a question:

Situation: On Thursday afternoon,
Behaviour: the pricing change was merged to main without a review,
           and the tests were failing on that commit.
Impact:    Checkout was broken for about 40 minutes, and two of us
           stopped our own work to roll it back.
Then:      Can you walk me through what happened? I'd like us to
           find a way to make sure it doesn't happen again.

The question matters. You may not know the whole story. Maybe a manager asked for an urgent fix, or the review tool was down. Listening first keeps the conversation about solving the problem.

Giving feedback well

• Ask first when it is not routine: "Do you have five minutes for some feedback on the demo?"
• Be timely. Feedback a day later is useful; feedback three months later at a review is not.
• Be private for constructive feedback, and public, if the person is comfortable with it, for praise.
• Focus on one or two points. A list of twelve problems overwhelms anyone.
• Use "I" statements for impact: "I was confused by..." rather than "Everyone was confused by...".
• Check understanding: "Does that match how you saw it?"

In written reviews, such as code or document reviews, the same rules apply. Comment on the work, not the person ("This function is hard to follow because..." rather than "You wrote this badly"), explain why, and separate must-fix points from suggestions.

Receiving feedback well

Receiving feedback is harder than giving it, because it can sting. A simple approach:

1. Listen to the end without interrupting or defending yourself.
2. Say thank you. The person took a social risk to tell you.
3. Ask clarifying questions to get specifics: "Can you give me an example?" or "What would good look like?"
4. Take time to think before you decide what to do. You do not have to agree on the spot.
5. Act and follow up. "I tried what you suggested in today's demo. Did it work better?"

Not every piece of feedback is correct. You can weigh it, look for patterns across several people, and decide. But you can only do that if you heard it properly first.

Common mistakes

• The "feedback sandwich" (praise, criticism, praise) used every time. People learn to ignore the praise and wait for the "but".
• Labels instead of behaviour: "lazy", "rude", "brilliant".
• Guessing intent: "You obviously didn't care about the deadline."
• Getting defensive when receiving, or arguing every point.
• Only giving negative feedback. Most teams need far more specific praise than they get.

Quick recap

• Use SBI: the situation, the observable behaviour, and its impact.
• Follow constructive SBI with a question and listen.
• Give feedback soon, privately when it is critical, and on one or two points.
• Receive feedback by listening, thanking, clarifying, then deciding.

Try it

Open the Do tab. You will write and practise SBI feedback, then ask someone for feedback yourself.