SBI vs FUKO: Which Feedback Model for Engineering Managers?

A blunt comment in an API review can leave you with two things to address: the technical concern nobody can act on and the way it landed with another team. Should you use SBI or FUKO to prepare that conversation?

I start with SBI + Feedforward when I need to clarify a behaviour and its operational impact. I choose FUKO when I also want to name my emotional response and make an expectation explicit. Both can work for the same conversation.

The FUKO feedback method takes its name from the Polish Fakty, Uczucia, Konsekwencje, Oczekiwania: Facts, Feelings, Consequences and Expectations. SBI uses Situation, Behaviour and Impact. Here, I pair SBI with Feedforward to add a future action; that fourth step is an extension, rather than part of SBI itself.

In an actual conversation, they often lead to a similar message:

• Be specific about what happened.
• Explain why it matters.
• Make the next step clear.

The difference is in what each model asks the person giving feedback to emphasise. FUKO gives feelings and expectations their own place. SBI separates the context from the observed behaviour, while Feedforward can turn the ending into a suggestion or a coaching question.

SBI + Feedforward and FUKO at a Glance

Here is the shortest comparison.

This table makes the models look like two ways to name the same four boxes. That is only partly true.

Facts in FUKO usually contain both the situation and the behaviour. Impact in SBI can include consequences, but it may also describe your reaction. Feedforward and Expectations both face the future, although they can create a different tone.

The structure changes where I slow down and what I am likely to say explicitly.

The Same Feedback in Both Models

Consider a cross-team design discussion. A senior engineer from the Payments team replied to a Platform API proposal with, “This design will not work for serious workloads,” without naming a failing scenario or measurement. The Platform team paused the rollout and the thread became defensive.

Using SBI + Feedforward

Situation: In yesterday’s shared API review thread…

Behaviour: …you wrote, “This design will not work for serious workloads,” without identifying the workload, failure mode or evidence behind the concern.

Impact: The Platform team paused the rollout but did not know what to test. The discussion shifted from the design risk to defending the teams’ competence.

Feedforward: In the next cross-team review, name the scenario you expect to fail and suggest evidence that would confirm or reject the concern. What would help you raise the risk that way?

Using FUKO

Facts: In yesterday’s shared API review, you wrote, “This design will not work for serious workloads,” without describing a failing scenario or evidence.

Feelings: I felt concerned because the message sounded dismissive of work another team had already shared for review.

Consequences: The Platform team paused the rollout without knowing what to test, and the thread moved away from the technical risk.

Expectations: When you challenge a cross-team design, describe the scenario, evidence and decision you need. Keep the criticism about the proposal rather than the team’s competence.

Both versions identify the same observable message and operational consequence. SBI makes the path from situation to behaviour especially explicit and ends with a coaching question. FUKO gives the manager’s relational response and the expected communication boundary their own place.

Either version can be directive or collaborative. The framework does not control tone; it changes which parts of the message I am less likely to omit.

Four Differences That Matter

1. SBI separates context from behaviour. “During yesterday’s design review” is the Situation; “you responded before each alternative was fully explained” is the Behaviour. FUKO usually contains both under Facts. SBI’s separation is useful when a judgement could hide inside a broad description.
2. FUKO gives Feelings their own step. SBI can include a reaction under Impact, but does not require it. I prefer FUKO when trust or the relationship is central, and SBI when the impact is mainly operational.
3. Impact and Consequences overlap. Both should describe an effect you can support with evidence. “QA lost a day of testing” is useful; “everybody lost trust in you” is an assumption unless people actually said it.
4. Feedforward invites a next attempt; Expectations state a standard. Feedforward fits coaching when several behaviours could improve the outcome. Expectations fit clear boundaries such as security rules, respectful conduct or an agreed escalation duty.

These are tendencies, not restrictions. A manager can name a feeling after SBI, ask a coaching question after FUKO or state a non-negotiable requirement in either model.

When to Use SBI vs FUKO

Choose based on what you need to make explicit in the conversation.

For the API review above, I would start with SBI + Feedforward if the immediate problem was missing evidence. If I also needed to explain my concern about how the comment landed, FUKO would give that response a separate place. In either case, I would ask what risk the engineer had spotted before agreeing on the next step.

Can You Combine SBI and FUKO?

You can, but I would not introduce a seven-letter feedback model to the team.

I prefer to choose one structure for the conversation and use the other as a preparation check.

If I prepare with SBI, I might ask:

• Is my emotional response relevant enough to name?
• Have I stated a real expectation, or only offered a vague suggestion?

If I prepare with FUKO, I might ask:

• Did I identify the specific situation?
• Did I separate observable behaviour from interpretation?
• Could the expectation become a useful feedforward question?

This gives me the benefit of both models without making the conversation sound like a training exercise.

The recipient does not need to know which acronym I used. They need to understand what happened, why it matters and what they can do next.

Common Mistakes in Both Feedback Models

The framework changes, but the most common mistakes remain the same.

The first is starting with a personality label and fitting it into boxes afterwards. “You were unprofessional” does not become a fact or a behaviour just because it appears after a bold heading.

The second is using feelings to create guilt. Your reaction can provide context, but the other person should not be asked to manage every emotion their manager experiences.

The third is exaggerating the consequence. “The whole team was demotivated” needs evidence. Describe what you saw and let other people speak for themselves.

The fourth is ending with an abstract instruction:

• Be more proactive.
• Communicate better.
• Show more leadership.
• Keep doing great work.

These phrases describe a direction, not a behaviour. Ask what the person should do in the next meeting, project update or incident.

Finally, both models can become a monologue. After describing the impact, pause. Ask what the other person saw, intended or understood differently. This is where empathy in engineering leadership turns a well-structured message into an actual conversation.

Pick One Model and Practise It

The best feedback model is the one you can use naturally when the conversation is uncomfortable.

I would not ask a team to memorise both at once. Choose one as the default. Practise it on positive feedback first, when the emotional stakes are lower. After a few conversations, notice what you tend to omit.

If feelings and boundaries disappear, borrow those questions from FUKO. If facts contain interpretation or the future step becomes too prescriptive, borrow the discipline of SBI and Feedforward.

If SBI fits your conversation, use the one-page SBI + Feedforward template (PDF). If FUKO fits better, use the one-page FUKO feedback template (PDF) and the examples in the full FUKO guide.