Decoupling Intent from Impact
Most engineering conflicts are not about malice — they are about misaligned incentives, unclear expectations, or communication failures. But when we are frustrated, we naturally reach for language that assigns blame ("you always do this") rather than language that describes facts. The SBI Framework (Situation → Behavior → Impact) is a structured way to give feedback that keeps the conversation focused on the problem rather than the person.
The core insight behind SBI is that people can argue about interpretations and intentions forever, but they cannot argue about observable facts and measurable consequences. By anchoring your feedback in specifics, you make it much harder for the conversation to become defensive.
The three components:
1. Situation (When and Where — the specific context):
- Ineffective: "You always break the build." — This is a generalization. The other person immediately starts thinking of counterexamples and stops listening.
- Effective: "During Tuesday's deployment to the staging environment at 3pm..." — This is a specific, verifiable fact. There is nothing to argue about.
2. Behavior (What — the observable action, not the interpretation):
- Ineffective: "...you were careless and didn't test your changes." — "Careless" is a judgment about character. It triggers defensiveness.
- Effective: "...the DATABASE_URL environment variable was not updated in the repository's config file before the merge." — This describes exactly what happened. No interpretation required.
3. Impact (The Result — business or team consequence, not your emotional state):
- Ineffective: "...and it made me really angry and stressed." — Your emotional state is real, but leading with it makes the conversation about you.
- Effective: "...which caused the QA team to lose 2 hours of testing time and pushed our release window back by a day." — This is a business consequence that both parties can agree is bad.
Putting it together:
"During Tuesday's staging deployment, the DATABASE_URL config wasn't updated before the merge, which cost the QA team 2 hours and pushed our release back a day. I want to figure out how we prevent this going forward."
Notice the final sentence: it pivots immediately to problem-solving. The goal of SBI is not to assign blame — it is to create a shared understanding of a problem so you can fix the process together.
When SBI is most valuable:
SBI is especially powerful in cross-team conflicts, performance conversations, and post-incident reviews. It is the difference between a blameless postmortem and a blame-full one.