Feedback on behavior, not on character

Feedback on behavior describes something a person did, so they can do it differently next time. Feedback on character labels who they are: “slow”, “careless”, “negative”. Hear a label and people defend who they are, and the conversation becomes an argument about character instead of a plan for next week.

A simple test: could a camera have recorded it? A camera sees two video tickets closed yesterday before the families confirmed the lesson worked. It sees the first EU messages waiting over two hours on Monday and Tuesday. It doesn't see “careless”, “lazy” or “doesn't care about families”: those are verdicts about character, guesses about what goes on inside someone.

At Klasna, “Bohdan is slow in the mornings” and “Taras is careless” are both labels. Each hides a specific, fixable behavior. Find the behavior first, with the day, the tickets and what happened, and the feedback becomes something the person can act on.

Good corrective feedback has a simple shape: the behavior, its impact, the next step, with one move inserted before the impact: ask how the person saw it. You may be missing half the story.

1. Describe the specific moment, so both of you talk about the same thing.
2. Ask for their view. It leaves room for facts you don't have.
3. Name the impact: why it matters for the team or families.
4. Propose a next step, and agree it together.
5. Set a date to look again, so it isn't a one-off remark.

Iryna gives you an example at Klasna. “On Thursday's call, when Taras asked about a refund, you answered in twenty seconds, before anyone else spoke. How did that moment look from your side?” You explain: the queue was long and you knew the answer. “Makes sense. The impact: since then, refund questions come to you, not to Olha's rotation. Next week, could you count to ten and ask ‘Olha, what would you do?’ We'll look at hand-ups on Friday.”

Many people learn to wrap criticizm in praise: something nice, the problem, something nice again. It feels kind. It doesn't work.

Three things go wrong. People learn to wait for the “but”, so every compliment starts to sound like a warning. The praise becomes insincere, because it's there to cushion, not because it was earned. And people often leave remembering the nice parts, not the change you asked for.

The fix is to keep the two apart. Give praise when it's earned, specific and on its own. Give correction directly and kindly, in the shape behavior → their view → impact → next step. Direct doesn't mean harsh: you can be warm in tone and clear in content at the same time.

A team that hears specific praise often, with nothing attached, stops bracing when the lead says “good work”, and that makes the corrections easier to hear too.

Praise is feedback too, and it follows the same rule as correction: name the behavior and its impact, so the person knows exactly what to repeat.

“Great job this week!” is pleasant and nearly useless: it doesn't say what was great. Compare: “Your rotation note on the video refund was so clear that Maryna solved it alone.” That names what was done (a clear note), and what it changed (a colleague solved a hard ticket without the lead). Now the writer knows what to keep doing, and the team hears what good looks like.

Three more rules. Give it when it's earned, not to soften something else. Give it soon, while both of you remember. And give it on its own, never as the bread around a correction.

Praise can be public more often than correction, as long as it's specific and fair across the team. A lead who only ever notices what goes wrong teaches people to hide their work.

The right words in the wrong place still fail. Two choices matter: timing and channel.

Timing: within a few days, while both of you remember the moment. Feedback saved for a quarterly or August review arrives when nobody can recall the ticket, and it feels like an ambush.

Channel: private, by voice or video. Corrective feedback in a team chat fails twice: tone gets lost in text, and everyone watches, so the person defends themselves in front of colleagues instead of thinking about the change. A call lets you hear each other's tone and ask “how did it look from your side?” in real time.

Then follow up in writing: a two-line summary of what you agreed and when you'll look again. In a remote team that summary is what both of you will check next week, and it prevents two different memories of the same call.

Email or chat alone, with no conversation, is a verdict delivered at a distance.

A single incident tempts a lead to generalise: one bad survey comment becomes “families find your replies cold”. Resist it. One case is one moment, and feedback should be about that moment.

At Klasna a family leaves a furious survey comment about Maryna's reply. Her satisfaction over two months is the team's best. What to do: read the ticket first. Maybe the family was angry about a cancelled lesson, not her reply. If the reply did have a real problem, talk with her about that one reply: what it said, how it landed, what she'd change.

Three moves get it wrong. Turning it into a trait (“your replies are cold”) makes one case a pattern. Ignoring it because her numbers are great dismisses a possibly real problem; averages don't make a single reply right. And sharing the comment in the team chat “as a lesson for everyone” makes corrective feedback public.

Never “you always” from a single case.

The reverse of “one case is one moment”: to say “this keeps happening”, you need several cases, and you should name them. “You often close tickets too early” is a label in disguise. “On the 3rd, the 5th and the 9th you closed refund tickets before the family confirmed the fix” is a pattern the person can check and act on.

Named cases also protect fairness. If you can't list them, maybe it isn't a pattern but an impression, built from one memorable ticket and a vague feeling.

Timing matters even more for patterns. Feedback held back until there are “enough” cases, or until the review season, lets the behavior repeat for months and then lands as a surprise. Olha says it from the other side at Klasna: she'd rather hear about one ticket on Tuesday than about “a pattern” at a review in August.

So raise the first case early, as one moment. If it repeats, you'll have the named cases, and the person will already know what you mean.

Before a feedback conversation, sort each part of your draft into keep or drop.

Drop labels (“you're too slow in the mornings”), and drop the sandwich bread: an opening compliment used to soften, and praise glued on at the end. The praise can go in its own message later.

Keep the observable behavior and the shared standard that explains the impact.

At Klasna the draft for Bohdan reads: “You're our most experienced person and families love you, but you're too slow in the mornings. Still, great job on the Teams invoices!” The facts behind it: on Monday and Tuesday he started his shift with the Teams invoices, and the first messages from EU families waited over two hours; the team's agreement says a first reply within 45 minutes on shift. Those two facts stay. Then ask before concluding: maybe the invoices have a deadline nobody told you about.

How it fits together: behavior instead of labels, the four-part shape, praise and correction kept apart, the right time and channel, and honest counts of cases. The next lesson turns it around: feedback going up, and the blind spots you can't see without it.