SBI Feedback Model + Feedforward for Engineering Teams

I had heard about the SBI feedback model earlier in my leadership journey. I liked how it kept feedback specific, but I always had the feeling that something was missing.

SBI helped me describe what had happened and explain its impact. Then it seemed to stop. The message might have been accurate, but the engineer could still leave with an uncomfortable question:

What should I do differently next time?

That was why I tended to choose the FUKO feedback model. Its final step, Expectations, gave me a clear place to say what I wanted to happen next. It felt complete to me.

Later, during the People Leader Experience training in my organisation, SBI was presented together with Feedforward. That was the missing piece for me. The combination is a practical synthesis, not a single canonical model: SBI comes from the Center for Creative Leadership, while Feedforward is a separate practice associated with Marshall Goldsmith.

SBI keeps the conversation grounded in a specific situation, observable behaviour and its impact. Feedforward turns the conversation towards the next opportunity. One explains why a change matters; the other makes that change easier to act on.

That small addition made the framework feel complete—and, more importantly, usable in a real conversation.

The complete structure is still short:

• Situation: When and where did it happen?
• Behaviour: What did the person do or say?
• Impact: What changed because of it?
• Feedforward: What could they repeat or do differently next time?

It works for difficult feedback, but also for recognition. In both cases, the purpose is the same: help somebody understand which behaviour produced which result, then make the next step clear.

What Is the SBI Feedback Model?

The Situation-Behavior-Impact model, usually shortened to SBI, was developed by the Center for Creative Leadership. CCL also describes SBII, which adds inquiry about intent. In this article, I keep SBI as the preparation structure and add Feedforward as a separate future-focused step.

Situation: anchor the conversation

Describe the moment in which the behaviour occurred.

• “In yesterday’s architecture review…”
• “During the production incident on Tuesday evening…”
• “When you presented the migration plan to the platform team…”

A useful situation is narrow enough that both people know which event they are discussing. “Recently” is vague. “In Tuesday’s sprint review” gives the conversation an anchor.

This matters because feedback often becomes an argument about memory. The more general the opening, the easier it is to produce a counterexample. “You never communicate risks” invites a debate about every risk the person has ever communicated. One real event gives you something you can examine together.

Behaviour: describe what a camera could record

Say what you saw or heard, without turning it into a judgement about the person.

In yesterday’s architecture review, you said, “Our architects create crappy architecture.”

That is behaviour: I am quoting what the engineer said. “You were disrespectful” is an interpretation. It may be how I experienced the situation, but it does not tell the engineer which words created that impression.

I use a simple test: could a camera or microphone have captured it?

If not, I am probably describing my story about the behaviour rather than the behaviour itself.

Impact: make the consequence visible

Explain what happened because of the behaviour.

The impact may be on:

• The delivery or technical outcome.
• Another person or team.
• Trust and collaboration.
• Your own ability to make a decision.
• The behaviour you want the team to repeat.

For example:

After that comment, we spent the next ten minutes discussing whether the criticism of the architects was fair. We finished the review without deciding how the services should communicate.

Impact is not a more polite place to hide a judgement. “The impact was that you showed poor ownership” still labels the person. A useful impact describes what changed in the work, the team or your experience.

SBI makes feedback specific. On its own, however, it can still leave the conversation looking backwards.

What Is Feedforward?

Feedforward is a future-focused suggestion. Instead of spending the whole conversation proving what was wrong, it asks what useful behaviour can happen at the next opportunity.

The idea is strongly associated with executive coach Marshall Goldsmith, who describes feedforward as suggestions for a future we can still change.

For an engineering manager, feedforward could sound like this:

In the next architecture review, please name the specific design decision you disagree with, explain the technical risk you see and suggest an alternative we can discuss.

That is more actionable than “be more respectful.” It describes a situation the engineer can recognise and an action they can take.

Feedforward can also be a question:

How could you raise the same technical concern next time so that we can discuss the design decision?

I prefer the question when the person has enough experience and context to design a good response. Their idea may be better than mine, and they are more likely to own it. I become more direct when expectations are non-negotiable or the person needs clearer guidance.

Feedforward does not mean pretending the past did not happen. If somebody caused an incident, missed an expectation or damaged trust, we still need to name it. The future step has meaning because SBI has made the reason visible.

Feedback without feedforward can become a diagnosis. Feedforward without feedback can feel like advice without context.

Together, they create a learning conversation.

SBI + Feedforward Example: Communicating Delivery Risk

Imagine that an engineer knew on Monday that a dependency could delay a feature. They continued investigating and mentioned the risk during Friday’s stakeholder meeting. By then, Product had already prepared the launch around the original date.

A vague version of the feedback might be:

You need to be more proactive and communicate better. We cannot have surprises like this.

The manager probably knows what they mean. The engineer has to translate three labels: “proactive,” “communicate better” and “surprises.” They may leave knowing the manager is unhappy, but not knowing what action was expected on Tuesday.

Using SBI with feedforward, the conversation becomes:

Situation: In Friday’s stakeholder meeting, when we discussed whether the feature was ready for launch…

Behaviour: …you said for the first time that the vendor dependency had put the delivery date at risk. You had discovered the problem on Monday.

Impact: Product had continued preparing the launch around the original date, so they had to change the customer communication with one working day’s notice. I also lost the opportunity to help remove the dependency earlier.

Feedforward: When a committed date becomes uncertain, please share the risk within one working day, even if you are still investigating. Tell us what you know, what you do not know and when you will update us. How would that work from your side?

The message is direct. It does not soften the consequence, and it does not call the engineer careless or passive. It connects one behaviour to an impact and defines what early communication should look like.

The last question matters. There may be context I do not have. Perhaps the engineer thought the vendor would respond within an hour. Perhaps every early warning has previously created panic. Perhaps I had unintentionally taught the team to bring me problems only when they also had a solution.

Understanding that context does not erase the impact. It helps us agree on a next step that will survive contact with real work.

Positive SBI Feedback and Feedforward

Feedback should not only appear when something goes wrong.

“Great job” is pleasant, but it gives an engineer very little information about what they should repeat. Positive SBI feedback makes good work visible and feedforward connects it to future opportunities.

Imagine an engineer leading a difficult incident review:

Situation: During this morning’s incident review…

Behaviour: …you walked us through the timeline before discussing individual decisions, and you asked two quieter team members for their observations.

Impact: The conversation stayed focused on the system rather than blame. We found the missing alert and heard an operational detail that had not appeared in the incident notes.

Feedforward: Please use the same structure for next week’s follow-up. I would also like you to share it with the other incident commanders.

This does more than recognise effort. It tells the person exactly which behaviour was valuable, why it mattered and where it could be useful again.

Specific positive feedback also teaches the wider team what good looks like. “Be a strong incident leader” is abstract. Build the timeline first, invite missing perspectives and keep the discussion on the system are behaviours people can practise.

How to Prepare SBI Feedback

Before the conversation, I write one or two sentences for each part. If the preparation becomes a page of notes, I probably have several conversations mixed together.

Use this simple SBI feedback template:

Situation: During [specific event or moment]…

Behaviour: I saw or heard you [observable action]…

Impact: This resulted in [effect on the work, team or me]…

Feedforward: Next time, [specific future behaviour]. What would you suggest?

Download the one-page SBI + Feedforward template (PDF). It includes the four prompts, a preparation checklist and space for the other person’s perspective.

Then check the draft:

• Is the situation specific enough to remember?
• Does the behaviour describe an action rather than a personality trait?
• Can I support the impact with something I observed?
• Is the next step inside this person’s control?
• Have I left room for their perspective?

The written structure is preparation, not a script you must read with a serious voice. In a real conversation, I want it to sound like one person talking to another.

After sharing the impact, pause. Ask what the person saw differently or intended. This is the inquiry added in CCL’s SBII extension. It prevents feedback from becoming a confident story built from incomplete information.

Intent and impact can both be true. An engineer may have intended to protect the team from noise and still have hidden a risk that others needed to see.

Common SBI Feedback Mistakes

• Do not fit a verdict into the labels. “In every meeting” is not a Situation, “you were negative” is not observable Behaviour, and “you damaged morale” needs evidence.
• Do not list five old situations at once. Start with one or two clear examples, then name the pattern.
• Do not borrow the team’s voice. Describe what you observed instead of claiming that “nobody trusts you.”
• Do not call an abstract demand Feedforward. “Be more senior” and “never do this again” do not describe a future behaviour.
• Do not prescribe ten steps when the other person can help design a better response.

Finally, avoid turning the structure into a monologue. Ask what the other person saw differently and listen before agreeing on the next step. That makes the message more accurate and helps build trust in engineering leadership.

When SBI + Feedforward Is Not Enough

SBI is useful for a single piece of feedback. It is not a complete performance-management process.

If the same behaviour continues, the conversation needs more than another carefully worded example. Clarify the expected standard, agree on how progress will be measured, provide support and document the follow-up. Repeated missed expectations should not be disguised as endless coaching.

The framework is also not a reason to delay urgent action. A security incident, harassment concern or serious safety risk may require escalation through the appropriate company process. You can still communicate in specific, factual language, but the priority is protecting people and the organisation.

For ordinary development conversations, however, this lightweight structure is often enough. It is easy to remember and short enough to use after a meeting, a code review, an incident or a presentation—not only during a formal performance review.

Use It in Your Next One-to-One

Choose one recent situation before your next one-to-one and write four sentences. Remove adjectives that describe the person. Make the impact concrete, then reduce Feedforward to one behaviour that can be tried at the next opportunity.

SBI provides the evidence; Feedforward makes it useful for the future. You do not need perfect words. You need a fair observation, an honest explanation of why it matters, space for the other person’s perspective and a next step they can use.

Download the one-page SBI + Feedforward template (PDF), prepare one real conversation and revise the framework after you hear the other person’s account.