Choose the most effective phrasing for delivering critical feedback in 5 real workplace scenarios.
The SBI feedback model: Situation → Behaviour → Impact
Situation: name the specific context — "In yesterday's sprint review..."
Behaviour: describe the observable action — "I noticed you interrupted [Name] twice"
Impact: state the effect — "It made it harder for the team to hear their proposal"
Forward: end with a development question — "What would help you avoid this in future?"
0 / 5 completed
1 / 5
A colleague consistently misses daily standup, causing the team to duplicate work. You decide to address it directly. Which approach is most professional and effective?
Why B is the model answer: SBI model + curiosity + solution-seeking
This response uses the SBI (Situation-Behaviour-Impact) model:
Situation: "this week" — specific time frame
Behaviour: "missed on Monday, Tuesday, and Thursday" — observable, not interpretive
Impact: "team has duplicated questions in Slack" — concrete effect on the team
Then crucially:
Curious question: "Is something getting in the way?" — creates space for the other person's context before judging
Solution-seeking: "find a solution that works for both of us" — collaborative, not punitive
Why A fails: "This is a problem" without specifics or curiosity reads as a complaint, not feedback. It triggers defensiveness.
Negative feedback phrases:
"I wanted to give you some feedback about [specific thing]."
"I've noticed [observable behaviour] and the impact is [effect]."
"I'm sharing this because I want [positive outcome] for you and the team."
"What would help you [change the behaviour]?"
2 / 5
You are a senior engineer and you notice a junior colleague's code quality has been declining — recent PRs have unhandled errors and no tests. You need to give feedback during a 1:1. Which approach is most effective?
Why B is the professional approach: starts with a positive, specifics, impact, confidence in the person
This uses the "feedback sandwich" structure thoughtfully:
Acknowledge a positive first: "great for feature delivery" — this is genuine, not a trick
Name the specific gap: "no test coverage, unhandled error paths" — observable, not vague
State the impact: "can cause production issues later" — explains why this matters
Express confidence: "I know you're capable of better" — distinguishes this from a performance judgment
Invite their perspective: "What's been going on?" — may reveal context (time pressure, unclear requirements)
Why "Others have noticed" (D) is harmful: invoking unnamed others is cowardly and makes the feedback impossible to address — it becomes about managing perceptions, not improving work.
Delivery phrases:
"I want to share some feedback — I'm doing this because I want to support your growth."
"I noticed [X] in [specific context]. The impact is [Y]."
"I'm confident you can [improvement]. What support would help?"
3 / 5
During a sprint retrospective, a colleague attributes the team's missed deadline entirely to "unclear requirements from the PO" but doesn't mention that their tasks were also delayed. You want to offer balanced feedback in the retro. What do you say?
Why C is the professional response: acknowledge the valid point, add nuance, redirect to full picture
This is a difficult situation: public retroactive feedback. The professional approach:
Acknowledge the valid part: "requirements clarity is worth discussing" — doesn't dismiss their point
Add the missing perspective: "delays were on the implementation side too" — introduces the fuller picture without attacking
Name a specific example: "[specific task] slipped mid-sprint" — grounded in data, not generalisation
Redirect to root cause analysis: "look at both" — reframes from blame to learning
Retrospective language principles:
Focus on process, not people
"What could we do differently?" not "What did [person] do wrong?"
Invite multiple perspectives before drawing conclusions
Useful retro phrases:
"I'd like to add another perspective to this."
"I think there are multiple factors worth looking at."
"Can we look at the full timeline together?"
4 / 5
A colleague is consistently late to meetings — at least twice a week. You've noticed it but never raised it. Today they arrived 10 minutes late to a client call. After the call, how do you address it?
Why C is the professional approach: private, specific, non-accusatory, and offers help
This response handles three challenges well:
Timing: after the call, privately — not during the call, and not at a team meeting
Specifics: "10 minutes late, noticeable to the client" + pattern over "a few weeks"
Stakes: explains why this particular instance was significant (client-facing)
Non-judgmental offer: "Is there something affecting your schedule that I can help with?" — creates space rather than issuing a warning
Why D is wrong: never use public forums to deliver individual performance feedback. It humiliates the person and destroys trust.
Pattern feedback phrases:
"I've noticed this a few times and I wanted to raise it directly."
"I'm bringing this up now because it's becoming a pattern."
"I'd rather give you this feedback than let it become a bigger issue."
5 / 5
You need to tell a junior developer that their approach to a task was incorrect and the work needs to be redone. The junior developer spent 2 days on it. How do you deliver this message professionally?
Why C is the model answer: honesty + shared accountability + learning opportunity
This is one of the hardest feedback situations — telling someone their work needs to be redone. The professional approach:
Be direct but compassionate: "won't meet our requirements" — clear, not softened into vagueness
Explain the specific reason: "[technical reason]" — gives them something to understand and learn from
Acknowledge the emotional weight: "hard to hear after two days of work" — validates the human element
Take shared responsibility: "I take some responsibility for not catching this earlier" — if you were involved in the design, this is honest
Turn it into a learning opportunity: "pair on the correct approach" rather than sending them away to redo it alone
Why B is harmful: fixing it silently denies the developer the learning opportunity and isn't sustainable — they'll make the same mistake again.
Rework feedback phrases:
"I need to give you some difficult feedback about [task]."
"The approach needs to change because [reason] — not because the effort wasn't good."
"Let's use this as a learning opportunity rather than just redoing it."