FUKO Feedback Model: Examples for Engineering Managers

FUKO is a four-part feedback model: Facts, Feelings, Consequences, and Expectations. It helps you describe what happened, why it matters, and what you want to happen next.

I used to think that good feedback depended on finding exactly the right words. In practice, the harder part was keeping the conversation specific. The moment I drifted from what happened into what I thought about the person, the discussion became defensive.

Example in Action

Consider this illustrative conversation about code review. An engineer has dismissed an alternative design without explaining the concern. Instead of saying “You are dismissive,” prepare something like this:

Facts: In yesterday’s review, you replied “This makes no sense” to the proposed retry strategy without explaining which failure case concerned you.

Feelings: I felt uneasy about how the disagreement was being handled.

Consequences: The author asked for clarification, and the technical question remained unresolved when the review ended.

Expectations: In the next review, describe the failure case and suggest a way to test it. What were you concerned about in this design?

The last question matters. You have described your perspective; now listen to theirs. If the facts are incomplete, correct your understanding before pressing for a change.

What is FUKO?

The letters come from Polish: Fakty, Uczucia, Konsekwencje, Oczekiwania. In English, I use Facts, Feelings, Consequences, and Expectations.

Facts describe an observable event. Name the occasion and the behaviour. “You did not post the update we agreed on for Tuesday” is something you can discuss. “You do not care about delivery” assigns an intention.

Feelings name your reaction. “I felt worried” gives the other person information about your experience. “I feel that you are unreliable” is a judgement presented as a feeling. Your emotions should provide context rather than make the recipient responsible for reassuring you.

Consequences explain the effect on the work or relationship. Be precise about what you know. If you do not know whether a delay affected a customer, ask rather than inventing an impact.

Expectations describe a future action. Replace “be more proactive” with when, where, and what to communicate. Leave room to discuss whether the person has the information, time, and authority to meet that expectation.

Example: A Delivery Risk Raised Too Late

Here is another illustrative scenario. A dependency was discovered on Monday, but the team first heard about its effect on the release on Friday.

Facts: You identified the vendor dependency on Monday and first raised the delivery risk in Friday’s stakeholder meeting.

Feelings: I felt concerned because I had been planning around the original date.

Consequences: Product had one working day to revise its customer communication, and we lost several days in which we could have explored alternatives.

Expectations: For this project, please post newly discovered risks to the delivery date in the project channel within one working day. Include what you know and when you will update us. What made it difficult to raise this one earlier?

That timing is an example of a team agreement, not a universal rule. Some risks require immediate escalation. Agree on what applies to your work and check that the escalation route is clear.

If the engineer says they expected to solve the dependency alone, discuss that assumption. If they had already raised it somewhere you missed, the feedback needs to change. Empathy in engineering leadership means taking that information seriously while still discussing the result.

Feedback Isn’t Just Criticism

Positive feedback is more useful when it explains what to repeat. Consider an engineer facilitating an incident review:

Facts: In today’s incident review, you built the timeline before discussing possible causes and invited two people who had not spoken to contribute.

Feelings: I appreciated how calmly you guided the conversation.

Consequences: We heard an observation about the missing alert that was not in the initial notes.

Expectations: Please use that structure in the next review and share how you prepared it. Which part helped you keep the discussion focused?

You do not need to read out four labels in the actual conversation. Use them to prepare, then speak naturally. Avoid praising early delivery in a way that implicitly asks someone to keep working unsustainable hours.

Why Use FUKO?

The model gives you a preparation check when a conversation feels uncomfortable. It helps you notice a missing fact, an exaggerated consequence, or a vague request.

It does not guarantee agreement or prevent defensiveness. Tone, timing, context, and your willingness to listen still matter. Nor does a four-part message replace ongoing coaching or your organisation’s process for serious conduct issues.

Try It in Your Next Conversation

Write one sentence for each element. Read the Facts line again: could someone else have observed it? Read the Expectations line: would the recipient know what to do differently next time?

Give the feedback privately when appropriate, ask for the other person’s account, and agree on any follow-up. If the real problem is an unclear handoff, use the delegation framework to repair the agreement as well as the conversation.