If you’ve ever rewritten a code review comment three times to make it sound less harsh, this is for you. Or maybe it’s the other side: someone left a “looks fine to me” on a PR you worked on for three days, and you have no idea whether they actually read it. Or the 1:1 where your manager said “just be more strategic” and walked out. Or the design review where three people said three different things and you left more confused than when you started.
Most tech women report two specific pains: giving feedback feels like nagging, and receiving feedback feels like a personal attack. Neither has to be true. The research on what makes feedback land is consistent and surprisingly old — Marcus Buckingham wrote about it in the Harvard Business Review in 2019, and the 2024 follow-up work (in HBR November 2024 and HBR’s performance reviews research) confirms the pattern: specific, behavioral feedback outperforms vague, personality-based feedback by roughly 2x in performance impact. Lara Hogan’s Resilient Management, written for new tech managers, gives you a four-step structure you can put on a sticky note.
This is the script. It’s the same script for code review and for 1:1s and for Slack messages. Read it once, practice it on something small, and you’ll never have to rewrite the same comment three times again.
Why “just be direct” is the wrong advice
You’ve been told “just be direct.” Maybe by a manager, maybe by a peer, maybe by the loudest person in the standup. Direct is good, right? Just say what you mean.
Here’s the problem. The research Marcus Buckingham and Ashley Goodall published in the original HBR Feedback Fallacy shows that feedback focused on what kind of person you are (“you’re not strategic,” “you don’t think about the customer”) is largely ineffective at changing behavior. Feedback that focuses on what you did in a specific moment (“yesterday in the standup, when you said X, the room got quiet”) actually moves the needle. The 2024 follow-up research from HBR — High Performers Need Feedback, Too and Performance Reviews That Actually Motivate — finds that this effect is even stronger for high performers and for people from underrepresented groups. Vague feedback falls harder on the people it was supposed to help.
So when someone tells you to “just be direct,” what they’re usually asking for is feedback that’s about them as a person. That’s the version that backfires. What actually works is feedback that’s about a specific behavior in a specific moment.
If you’re a woman in tech, you’ve probably internalized the version where direct feels like nagging. That’s not because you can’t be direct. It’s because the version of “direct” you were handed is built on the wrong model — the personality-judgment model, not the behavior-observation model. Switching to the behavior model is what makes feedback land cleanly on the other side.
That shift matters a lot when you’re early in your tech career and the feedback pile feels relentless — your first 1:1s, your first code reviews, your first performance review. The women who broke into tech report that the first six months are full of feedback that doesn’t follow this script, and learning to recognize the difference between behavioral and personality feedback is what gets you through it.
The 4-step SBI-Q feedback script
This is the version I use, adapted from Lara Hogan’s Resilient Management “feedback equation” and the broader SBI family of feedback models. It works in code review, in 1:1s, in Slack, and in performance reviews. Four steps:
- Situation. Anchor to a specific moment. “In yesterday’s standup,” or “in your PR comment from this morning,” or “in the meeting at 2pm.”
- Behavior. Describe the observable behavior. Not “you were dismissive” — that is a judgment. “You said ‘that’s a dumb question’ to Sam’s question about the database.” That is observable.
- Impact. Name the impact on the team, the project, or you. “Sam went quiet for the rest of the meeting.” “I had to spend 30 minutes re-explaining the context.” “Two people DM’d me afterward asking if that was normal.”
- Question. End with an open-ended question instead of a command. “What was going on for you in that moment?” or “How were you hoping that would land?” or “Is there something we should be doing differently as a team?”
The first three steps get the observation on the table. The fourth is what flips feedback from a one-way broadcast into a conversation. Most people skip the fourth step, and that’s why feedback feels like nagging — because nagging is feedback without the question. The question is what makes the other person a participant.
If you’ve ever practiced a code review comment out loud three times before posting it, you already know this pattern. The same hesitation shows up in interview prep when you’re crafting your “tell me about a time you got tough feedback” answer — there’s a version that lands and a version that doesn’t, and the difference is whether you can describe the behavior and the impact without the personality label.
Giving feedback: 3 code review examples
Code review is where feedback patterns get baked in for the rest of the team. If your reviews are sharp, your team will be sharp. If your reviews are vague, your team will write vague code. Three real-world examples, rewritten the way the 4-step script suggests:
Example 1: The vague PR comment
What you wanted to say: “This is overcomplicated. Just use the existing helper.”
Why it lands badly: “Just use” sounds like a command. “Overcomplicated” is a judgment, not an observation. The author has no way to engage with the technical point.
SBI-Q version: “In your PR this morning, you wrote a custom retry loop around the API call (lines 142-160). We already have retry_with_backoff in utils/net.py that handles the same exponential backoff. When we use the custom version here, it’s harder for the next person to spot that the retry is intentional — it just looks like a bug. Could you switch this to retry_with_backoff and add a one-line comment about why we want the backoff in this specific call?”
Notice the structure: the situation is anchored (your PR this morning, line numbers), the behavior is described (custom retry loop), the impact is named (looks like a bug, harder for next person), and the question/request is specific (switch to X, add a comment). No personality label.
Example 2: The implicit-knowledge gap
What you wanted to say: “This won’t scale. You need to think bigger.”
Why it lands badly: “Think bigger” is a personality judgment (“you’re not thinking big enough”) and offers no information about what the actual constraint is.
SBI-Q version: “In the architecture doc you posted, the user table is queried once per request (section 4.2). When we hit 10k concurrent users next quarter, that becomes the bottleneck — at our current row count we can serve ~2k requests/sec on that table before latency crosses 100ms. What do you think about denormalizing the user profile into the session cache, the way the payments team did in Q1?”
You’re naming the situation (the doc, the section), the behavior (the query pattern), the impact (the latency math), and ending with a question that opens up the conversation instead of closing it.
Example 3: The tone mismatch in review
What you wanted to say: “Why didn’t you just ask me before doing this?”
Why it lands badly: The word “just” implies the answer should have been obvious. It’s a way of saying “you should have known” without saying it — which makes it land even harder.
SBI-Q version: “In the migration script you committed yesterday, you made a one-line schema change to the users.email column. That’s a change I usually expect to see in a doc first — there are downstream consumers (the email service, the analytics pipeline) that I’d want to flag. I’m not upset, I just want to make sure we’re aligned. Can you walk me through how you decided to do this without a doc?”
This is the version where you’re naming the impact on the team (“downstream consumers I’d want to flag”) and asking a question that might surface something you didn’t know — maybe they had a reason, maybe they didn’t realize. Either way, you find out.
Giving feedback: 3 1:1 examples
Code review has structure — there’s a PR diff to anchor to. 1:1s are messier, because the topic can be anything and the other person is sitting across from you looking at your face. Lara Hogan’s Resilient Management is mostly about this — the structure of feedback when there’s no diff to point at. Three examples:
Example 4: The promo feedback conversation
What you wanted to say: “You’re not ready for promotion. You need to lead a bigger project first.”
SBI-Q version: “I want to walk through what I see as the gap between where you are and the senior bar. The senior bar at our company includes leading a cross-team project end-to-end. The work you’ve done so far has been within-team and high-quality, but it hasn’t been visible across the org. That’s the gap. What project would you want to lead in the next six months that would close that gap?”
Notice you’re naming the gap, naming the impact (“hasn’t been visible across the org”), and asking them to propose the path. That’s HBR’s “How to Ask for the Feedback You Really Need” applied to the giving side — both people leave with more clarity than they came in with.
Example 5: The meeting behavior conversation
What you wanted to say: “You keep talking over people in meetings. It’s a problem.”
SBI-Q version: “In yesterday’s design review, three people tried to speak and you took each of their turns — Maya’s, then Sam’s, then Priya’s. Two of them dropped out of the conversation entirely after that. I want to make sure the meeting is using everyone’s input. Can we talk about what was happening for you in that moment?”
This is where the question is doing the most work. The behavior is on the table. The impact is concrete (two people dropped out). The question is genuine — maybe there’s a reason, maybe they didn’t notice. You find out.
Example 6: The style, not substance, feedback
What you wanted to say: “Your code is fine but your documentation is bad.”
SBI-Q version: “I tried to onboard onto your service this week and I couldn’t get past step 3 without DMing you. The README jumps from ‘run this script’ to ‘deploy to staging’ with no middle section. What I needed was a section called ‘first 30 minutes’ that walks through what the script does and what state it leaves the system in. Would you be willing to add that section?”
You’re naming the situation (your attempt to onboard), the behavior (no middle section in the README), the impact (you couldn’t get past step 3), and the question/request is specific and small enough to actually do.
Receiving feedback: the question that turns a critique into a growth loop
The harder half of feedback is on the receiving side. Most tech women report that receiving feedback feels like a personal attack — partly because the feedback is often framed as a personality judgment (“you don’t think strategically”), partly because of the imposter-syndrome backdrop, and partly because the research on code review pushback shows that women and underrepresented developers get more pushback, more aggressive language, and more unsolicited style criticism than their peers.
Here’s the receiving-side script, adapted from HBR’s “How to Ask for the Feedback You Really Need”:
- Breathe. Don’t respond in the first 30 seconds. Your nervous system is doing a thing; let it finish.
- Ask one clarifying question. “When you say X, do you mean Y or Z?” Specificity is the goal.
- Name what you heard. “So what you’re saying is, in the last PR, the variable naming made it harder to scan. Got it.”
- Decide what to do. “I’m going to rename the variables in this PR and try the new naming style for the next two weeks. I’ll check back in then.”
The clarifying question is the load-bearing step. It converts a vague critique into a specific change. “Can you be more strategic?” becomes “do you mean in the planning doc, or in code review comments, or in meetings with the product team?” Each answer gives you something to work with. Each one is small enough to do.
The naming step is the part most people skip, and it’s the part that makes feedback land. When you say “so what you’re saying is X,” you’re doing two things: you’re confirming you actually heard the feedback (which the giver almost never believes), and you’re translating a vague impression into a concrete behavioral change. HBR’s May 2024 article documents the pattern — the people who ask for behavioral specificity before responding to feedback get more usable feedback and more of it.
The same script works for receiving resume feedback from a mentor or peer. If someone reviews your tech resume and says “this feels generic,” the clarifying question is the same: “do you mean the summary, the bullet points, or the order of the sections?” Each answer gives you a small specific change to make. Peer mentors in tech often give the best resume feedback because they’ve read hundreds — but only if you can get from their general impression to a specific change.
This is also the script to use when the feedback is unfair. You can name what you heard, disagree with the framing, and still leave the conversation with something to work with. “I hear that you found the doc hard to read; I disagree that the structure is the problem and I think the missing context is on the consuming team — but I’m going to add a one-paragraph summary to the top anyway.” That’s disagreement without escalation.
When feedback fails: the 3 patterns that should make you walk it back
The 4-step script works in most situations. It doesn’t work when the feedback itself is destructive. The research on this is clearer than you’d expect: the 2022 CSCW paper “Destructive Criticism in Software Code Review Impacts Inclusion” (Google Research / Emerson Murphy-Hill et al., surveying 93 practitioners with 43 women) found that women perceive destructive feedback as significantly less appropriate and are less motivated to continue working with destructive reviewers — at similar frequencies of receiving destructive feedback, women were significantly more likely to disagree that the feedback was acceptable. The CACM follow-up “Pushback Effects of Race, Ethnicity, Gender, and Age in Code Review” confirms the pattern: higher odds of receiving pushback for women and underrepresented groups.
Three patterns should make you walk the feedback back rather than push it forward:
Pattern 1: Personality label, not behavior
If the feedback is “you’re not detail-oriented” or “you don’t have good taste” or “you’re sloppy” — that’s a personality judgment, not an observation. There is no behavior to point at, no situation to anchor to. Walk it back. Ask: “Can you point me to a specific moment? What was happening, what did you see me do, what was the impact?” If they can’t answer concretely, the feedback is a vibe, not a behavior.
Pattern 2: The derailing tone
If the feedback arrives with words like “obviously,” “clearly,” “you should have known,” “this is wrong,” “that’s a dumb question” — that’s derailing tone, not feedback. The CSCW 2022 study specifically tracks this kind of phrasing. You can name it: “I noticed this comment used the word ‘obviously.’ That phrasing makes it harder for me to engage with the technical point. Can we focus on the code?” This is the script from HBR’s November 2024 research on what makes reviews actually motivating.
Pattern 3: The flood
If you get six pieces of feedback in one conversation, you can’t act on any of them. Lacerenza et al.’s 2017 meta-analysis on leadership training (which is the closest thing we have to a meta-analysis on feedback transfer) found that feedback specifically improves training transfer — the on-the-job behavior tier — but only when it’s small enough to act on. The same pattern shows up in performance reviews: HBR’s November 2024 performance reviews research documents that people who get 3+ feedback items per review act on fewer of them than people who get 1-2. Walk it back: “I want to do this right. Can you pick the one that matters most this quarter and we can come back to the rest in 6 weeks?”
The 4-step script doesn’t survive these patterns. None of them are about a specific behavior in a specific moment, so there’s nothing to anchor to. The right move is to name what you see, redirect to the smaller specific feedback, and document the conversation if the pattern repeats.
Conclusion: your 4-step card
Here’s the script, on a card. Print it. Stick it on your monitor. Use it on the next code review, the next 1:1, the next Slack thread.
Situation — anchor to a specific moment.
Behavior — describe the observable action.
Impact — name the impact on the team, the project, or you.
Question — end with an open-ended question instead of a command.
That’s it. The script is the same for code review and 1:1s and Slack messages. The pattern doesn’t change because the medium changes. What changes is your willingness to do the fourth step — the question — which is the step most people skip because it makes feedback feel slower. It does. It also makes feedback work. The tradeoff is worth it.
For more on the day-to-day work patterns that make this sustainable (especially when you’re early in your tech career and the feedback pile feels relentless), the first-year tech manager guide walks through how to keep this kind of feedback loop going without burning out. If you’re navigating a promotion conversation and want the receiving-side script in that context, the asking for promotion in tech post has the worked examples. And if you’re returning to tech after a career break and the feedback feels like a re-orientation rather than a critique, the return to tech guide has the orientation frame.
The research says feedback transfers when it’s specific, behavioral, and small enough to act on. The 4-step script gives you that. The question at the end is what makes it a conversation instead of a broadcast.
Frequently asked questions
What is the SBI-Q feedback script?
SBI-Q stands for Situation, Behavior, Impact, Question. It’s a four-step feedback structure: anchor to a specific moment, describe the observable behavior, name the impact, then ask an open-ended question instead of commanding a change. Lara Hogan’s Resilient Management describes a similar “feedback equation” (observation + impact + open-ended coaching question). The HBR articles on the Feedback Fallacy and performance reviews that actually motivate show that this specific-and-behavioral approach outperforms vague personality-based feedback by roughly 2x in performance impact.
How do you give tough feedback without sounding harsh?
Describe the behavior (not the person), name the impact on the team or project, and ask a coaching question. Skip personality labels entirely (“you’re lazy,” “you’re disorganized,” “you don’t think strategically”). Replace them with observable actions anchored to a specific moment. The HBR November 2024 article on high performers specifically notes that vague feedback falls harder on people from underrepresented groups — so the specificity isn’t a “nice to have,” it’s the difference between feedback that helps and feedback that hurts.
How do you receive code review feedback without taking it personally?
Separate the feedback from the delivery. Ask one clarifying question: “When you say X, do you mean the variable name, or the logic flow?” That converts a vague critique into a specific, actionable change. HBR’s May 2024 article on asking for feedback documents that people who ask for behavioral specificity before responding to feedback get more usable feedback and more of it. The pattern is especially important given the CSCW 2022 research on destructive code review feedback showing that women and underrepresented developers get more pushback and aggressive language in reviews.
What do you do when feedback is unfair or destructive?
First, name what you observed: “I noticed that comment used words like ‘obviously’ and ‘this is wrong.’ That’s the kind of phrasing that makes it harder for me to engage with the technical point.” Then redirect: “Can we focus on the code?” If the pattern repeats, document it. The CACM research on pushback effects shows that this kind of destructive feedback is not evenly distributed across the team — documenting the pattern (in your own notes, in your 1:1s with your manager, or in HR systems where they exist) is part of how you advocate for yourself and for the people who come after you on the team.
