Master the SBI (Situation-Behavior-Impact) framework to deliver constructive peer feedback, receive tough code/performance critique without getting defensive, and drive your 1:1 career growth.
Feedback is the single fastest feedback loop for engineering growth. In high-performing software engineering orgs (such as Google, Razorpay, Flipkart, and Atlassian), continuous feedback occurs daily during PR code reviews, pair programming, sprint retrospectives, and 1:1 manager syncs.
However, giving feedback poorly creates resentment, while receiving feedback defensively halts professional growth. Mastering actionable feedback using the SBI (Situation-Behavior-Impact) framework, processing critical critique with curiosity rather than ego, and proactively asking senior leads for specific areas of improvement turns feedback into a career superpower.
Apply the SBI (Situation, Behavior, Impact) framework to structure objective, constructive feedback.
Depersonalize technical and performance critique by separating individual self-worth from code quality.
Harvest actionable micro-feedback from senior engineers and managers during regular 1:1 syncs.
Transform vague critique ("Be more proactive") into specific 2-week execution plans.
Deliver specific, positive reinforcement (`praise:`) that boosts team psychological safety.
Helps resolve team slacking and code integration friction during capstone projects and hackathons.
Proactively soliciting feedback from managers during 1:1 syncs is the #1 predictor of PPO offer conversions.
Drives rapid career advancement from Junior to Mid-Level engineer within 12-18 months.
Gathers client feedback midway through milestones to prevent late-stage project rejections.
Navigates maintainer feedback on complex pull requests with professional composure.
Evaluated heavily in FAANG Behavioral and Culture Fit rounds ("Tell me about a time you received tough feedback").
Allows Engineering Managers and Tech Leads to coach underperforming team members constructively without demotivating them.
Creates a culture of high trust, psychological safety, and continuous improvement across the engineering org.
Structure constructive feedback into 3 objective components: 1) Specific Situation (When/Where), 2) Observable Behavior (What happened), 3) Concrete Impact (Effect on system or team).
Pro Tip: Script format: "During yesterday's staging release (Situation), when the API schema was updated without updating `.env.example` (Behavior), it blocked 3 QA engineers from running tests for 2 hours (Impact)."
View code critique and performance feedback as telemetric data about software and habits, not as an evaluation of your personal worth as a human being.
Pro Tip: Replace "I am a bad programmer because my PR was rejected" with "My PR had a concurrency flaw that I can fix with Redis locks."
Don't wait for annual performance reviews. Ask your tech lead or manager for micro-feedback during regular bi-weekly 1:1 syncs.
Pro Tip: Script format: "What is 1 specific area I can improve in my next sprint implementation?"
When receiving feedback, acknowledge it, create a 2-week action plan, and follow up with the provider to demonstrate concrete progress.
Pro Tip: Follow-up script: "Two weeks ago you noted my PR descriptions lacked test plans. I have added automated test tables to my last 3 PRs—how does this look to you?"
Dev Lead gave SBI feedback to developer who merged un-tested DB schema changes. Explained situation, observable behavior, and 2-hour QA blockage impact.
Manager noted intern was hesitant to speak up during architecture syncs. Intern thanked manager, prepared 3 bullet points before every design meeting, and active-participated consistently.
Maintainer requested complete rewrite of a state management hook. Contributor replied: "Thank you for highlighting the re-render issue! I see why `useMemo` is needed here," and updated PR in 24 hours.
✕ Bad Approach
Engineer: "Hey, you keep pushing broken code and crashing staging. Pay attention next time!"
Why it failed: Aggressive, generic, lacks specifics, and triggers defensive arguments.
✓ Better Approach
Engineer: "Hey Vikram, do you have 5 minutes to chat? During yesterday's release deployment (Situation), when PR #120 was merged without running local integration tests (Behavior), it caused a 500 server error on staging that blocked QA testing for 2 hours (Impact). Moving forward, can we agree to run `npm run test:integration` before merging? I am happy to help set up a GitHub pre-commit hook to automate this!"
Why it works: Uses SBI framework, keeps tone professional and empathetic, and offers a collaborative automated solution.
✕ Bad Approach
Developer: "Well, the requirements were confusing anyway, and I didn't have enough time because DevOps was slow!"
Why it failed: Defensive, shifts blame to others, and demonstrates low ownership.
✓ Better Approach
Developer: "Thank you for sharing that feedback, Rahul. I hear you that my PR updates were submitted late in the sprint, which squeezed our QA testing window. To prevent this next sprint, I will break my tickets into smaller 1-day sub-tasks and flag any backend blockers on Slack by mid-week. Let's check in on this during our next 1:1 in 2 weeks to see if my timing improves."
Why it works: Acknowledges impact without defensiveness, takes ownership, and offers a concrete 2-week action plan.
✕ Bad Approach
Developer: "Am I doing good?"
Why it failed: Vague prompt that forces manager to give generic "Yeah, you're fine" responses.
✓ Better Approach
Developer: "In our last sprint release, I owned the Redis caching layer. What is 1 thing I could have done better in terms of technical execution or cross-team communication?"
Why it works: Specific, low-friction, and invites actionable micro-feedback.
Hi Priya! In our last 1:1, you suggested I take more ownership in team architecture reviews. Over the last two weeks, I wrote the RFC document for our Auth Service Redis caching migration. How did you feel about my technical presentation in Tuesday's review?
You did a great job framing the latency benchmarks! One area to refine: when Security Lead raised concerns about token expiration, you answered a bit defensively. Next time, acknowledge their security risk first before presenting the Redis TTL data.
That is super helpful insight. I see how acknowledging security concerns upfront builds trust. In our upcoming Payment API review next week, I will explicitly list security constraints upfront before diving into latency data.
Fix: Critiquing a peer in public channels like `#general`. Always give personal constructive feedback in private 1:1 calls or DMs.
Why it happens: Public calling out causes humiliation and destroys psychological safety.
Fix: Immediately making excuses when given feedback. Pause, listen, and say "Thank you, let me digest this and trace the issue."
Why it happens: Defensiveness signals to managers that you are difficult to coach.
Fix: Saying "Good job" or "Do better". Use SBI to make both praise and critique specific and actionable.
Why it happens: Vague feedback cannot be repeated or corrected.
Fix: Gather micro-feedback bi-weekly during regular 1:1 syncs while context is fresh.
Why it happens: Delayed feedback loses context and prevents real-time course correction.
Format feedback into Situation, Behavior, and Impact.
Tip: Keeps feedback objective, fact-based, and free of emotional judgments.
Praise peer achievements in team Slack channels, but deliver constructive critique in 1:1 DMs.
Tip: Builds public morale while protecting individual psychological safety.
If an incident makes you angry, wait 24 hours before delivering feedback.
Tip: Ensures feedback is delivered with emotional composure and clear objective facts.
Hey [Name], do you have 5 minutes for a quick 1:1 chat? - **Situation:** During [Specific Event/Meeting/PR, e.g. yesterday's staging deployment]... - **Behavior:** When [Observable Action, e.g. the DB schema migration was merged without running test seeds]... - **Impact:** It caused [Concrete Effect, e.g. 500 API errors that blocked QA testing for 2 hours]. Moving forward, can we agree to [Proposed Solution/Process, e.g. run local integration tests before merging]? I'm happy to help [Offer support, e.g. set up automated CI checks]!
💡 Usage Guidance: Use this template when preparing to give constructive feedback to a peer or junior engineer.
Hi [Manager Name], In our sprint work on [Project/Feature Name], I want to make sure I am operating at the standard expected for [Role Level, e.g., SDE-1]. 1. What is **one specific technical area** where my implementation met or exceeded expectations? 2. What is **one specific area** (code quality, communication, timing) where I can improve my execution in the next sprint?
💡 Usage Guidance: Script to copy and paste into your bi-weekly 1:1 manager document.
The SBI Feedback Conversion Drill: Take a past frustration with a team project and write out a 3-sentence SBI feedback script (Situation, Behavior, Impact).
The 1:1 Manager Feedback Script Practice: Draft 3 specific questions to ask your manager or lead in your next 1:1 to gather targeted actionable feedback.
The "Zero-Defensiveness" Challenge: Commit to responding with "Thank you for that perspective, let me trace that issue" to the next 3 PR comments you receive.
Roleplay Feedback Delivery: Practice delivering tough SBI feedback to a peer with a study partner.
Common behavioural and technical interview questions testing this competency across experience levels.
💡 Model Answer Framework:
I separate my personal self-worth from my code. I treat feedback as telemetric data on system quality. I thank the reviewer, ask clarifying questions if anything is unclear, and reply with the commit reference once resolved. If I disagree technically, I present benchmark data respectfully in a quick sync.
Feedback is the single fastest catalyst for engineering skill development.
The SBI framework keeps feedback objective, empathetic, and actionable.
Coachability and zero defensiveness build trust with senior leaders and interviewers.