Receive then seek: "Thanks — can you give me a specific example?" — for receiving feedback
Options not problems: "I can do X by Y or Z by W" — for deadline pushback
Frame → Evidence → Alternative: for technical disagreements
0 / 5 completed
1 / 5
Your team is falling behind on sprint goals due to scope creep added unilaterally by the product manager. In the sprint retro, how do you raise this professionally?
Why C is the SBI (Situation–Behaviour–Impact) model
The SBI feedback framework raises issues without blame:
Situation: "this sprint" — specific time context
Behaviour (observable, not judgmental): "three tasks were added mid-sprint that weren't in the initial scope" — fact, not accusation
Impact (quantified): "20% increase in workload without timeline adjustment"
Forward-looking: "I'd like to discuss how we handle scope changes" — proposes a systemic fix, not personal blame
SBI avoids:
Personal accusations ("the PM ruined")
Sweeping judgements ("this sprint failed because of X")
Silencing ("everything is fine")
Retro raising-issue templates:
"One thing I noticed was [behaviour]. The impact was [X]. I'd like to explore [solution]."
"I want to name something: [pattern]. Can we discuss how to handle this differently?"
2 / 5
A colleague's PR has fundamental architectural issues. Your review is honest but you want to avoid making them defensive. Which comment is most effective?
Why C is the model code review comment: acknowledge → specific concern → suggestion → offer
Effective technical feedback has four parts:
Acknowledge what works: "This approach will work" — not dismissive
Specific concern with rationale: "tightly coupling auth to request layer → harder testing/changes" — explains WHY, not just "it's wrong"
Constructive suggestion: "I'd suggest extracting it to a service class"
Collaboration offer: "happy to pair on this" — signals support, not just criticism
Why the others fail:
A: "Please redo it" — command without explanation, demotivating
B: Vague and non-actionable — what should they think about?
D: False approval is a disservice to the colleague and the codebase
PR comment softening phrases:
"I wonder if [alternative] might work better here because…"
"One thing to consider: [concern]. Not a blocker, but worth thinking about."
"Nit: [minor thing] — feel free to ignore if you disagree."
"This could lead to [issue]. What do you think about [alternative]?"
3 / 5
Your tech lead gives you feedback that your code is "hard to read." You disagree — you think it's clean and well-structured. How do you respond?
Why C is the model response: receive graciously, seek specifics
When receiving feedback you disagree with, the professional move is to seek specific evidence before accepting or defending:
Acknowledge: "Thanks for the feedback" — receive graciously regardless of agreement
Seek specifics: "Could you point to a specific part?" — actionable and reasonable
Tie to your intent: "I want to understand where readability breaks down" — signals openness to learning
Practical framing: "make sure I fix the right things" — professional, not defensive
Why the others fail:
A: Immediate pushback without seeking evidence — defensive, shuts down the conversation
B: Blind compliance without clarity — you might rewrite the wrong things
D: "Different styles" — in a team context, readability is a team concern, not personal preference
Receiving feedback professionally:
"Thanks — can you give me a specific example?"
"I appreciate the feedback. Help me understand what you mean by [X]."
"That's useful to know — what would the ideal version look like?"
4 / 5
You're asked to deliver a feature by Friday, but you know it's not achievable without cutting corners. How do you communicate this to your manager?
Why C is the model response: honest + specific + options
The professional way to push back on a deadline:
Evidence of consideration: "I've looked at the scope carefully" — shows you've thought about it, not just resisting
Specific concern: "Friday deadline isn't realistic for production-quality code" — grounds the concern in quality, not personal capacity
Options, not just problems: "[subset] by Friday OR full feature by [date]" — gives the manager choices
Collaborative close: "Which would work better for the release plan?" — invites their input on the trade-off
The key principle: Bring options, not just problems. A manager wants to know you've thought about solutions, not just identified obstacles.
Deadline negotiation phrases:
"I want to flag a risk with the [date] deadline…"
"I can do [X] by [date], or [Y] by [later date]. What's the priority?"
"If we scope it to [smaller version], I'm confident we can hit [date]."
"I don't want to commit to a date I can't hit — can we align on a realistic one?"
5 / 5
In a design meeting, you believe a proposed architectural decision is wrong and could cause serious problems. What is the most effective way to make your case?
Why C is the model technical disagreement: framed pushback + evidence + alternative + time-bounded ask
Effective technical disagreement in a meeting follows the frame → evidence → alternative → time ask pattern:
Signal respectful disagreement: "I'd like to push back on this one" — normalises healthy debate
Specific technical concern: "my concern is [X]" — not personal, grounded in engineering
Evidence: "I've seen a similar pattern cause [Y] in [context]" — experience-backed
Stakes: "the risk is significant enough" — calibrates urgency
Alternative: "explore [alternative]" — constructive not just critical
Bounded ask: "Can we take 10 minutes?" — small, reasonable commitment
Technical disagreement phrases:
"I'd like to raise a concern about [approach]."
"Have we considered [alternative]? Here's why it might address [risk]…"
"I've seen this pattern before and it led to [problem]. Worth discussing?"
"I'm not convinced this is the right call — can we talk through the trade-offs?"