Feedback usually goes wrong in the delivery, not the content. The manager is right about the problem. Then the conversation happens three weeks late, wrapped in compliments, in a review the engineer didn't see coming, and the point never lands.
We don't read that as a character flaw. Plenty of engineering managers got the job for being good engineers and learned feedback by trial and error, mostly error. It's a skill, and it can be practised like any other.
Three ways it goes wrong
Waiting until you're annoyed. If you only raise something after it has bothered you for a fortnight, the irritation comes along with it. The engineer reacts to your tone and spends the conversation managing you instead of hearing the point.
Being vague. "You need to communicate better" can't be acted on. Better how? With whom? If the person can't turn what you said into something they'll do differently on Monday, it was a complaint.
Saving it up. Feedback that waits for the performance review lands as a verdict on a quarter that's already over. Nobody can change last March.
Situation, behaviour, impact
The most useful structure we know comes from the Center for Creative Leadership, which has taught it to managers for decades. Sloan Weitzel's short book Feedback That Works is the standard write-up. It has three parts:
- Situation: the specific moment. "In yesterday's design review…"
- Behaviour: what you saw or heard, not what you concluded. "…you interrupted Priya twice before she'd finished her proposal…"
- Impact: what it caused. "…and she didn't speak again, so we never heard her view on the caching approach."
What it leaves out matters as much as what it includes. There's no "you're dismissive", no "you always do this" and no guess at why they did it. Guessed motives are where feedback conversations turn into arguments, and the guess is often wrong anyway.
We think the model is undersold for positive feedback. "Great job on the migration" is pleasant and forgotten by Friday. "You paired with the new hire instead of just reviewing their PR, and they've shipped their last three changes without help" tells the engineer exactly what to keep doing, and they'll remember you noticed.
Make it ordinary
Teams where feedback works tend to have more of it, in smaller pieces. When some small correction comes every week, no single one feels like a judgement. A few habits that help:
- Put it in the 1:1. Ask what you could do differently, then wait. The first answer is usually "nothing". The real one tends to come once the silence gets uncomfortable.
- Say which hat you're wearing. Someone learning a new skill needs coaching, and coaching that sounds like grading stops them trying things. Tell them which conversation this is.
- Notice when it worked. If someone changes after your feedback, say so. It costs you a sentence and it's the habit managers drop first.
When it's hard
Some conversations are hard however you open them: a strong engineer whose behaviour is wearing the team down, or a performance problem that hasn't moved in two months. The pull is to soften the message until it no longer says anything. Don't. Someone who knows where they stand can do something about it. Someone left guessing can't.
Being clear doesn't mean being harsh. Have the conversation in private, say the difficult part plainly, and only say you believe they can close the gap if you do. You want them to leave knowing what the gap is and what closing it would look like. Whether they agreed with every word matters less.
Where this sits in the standard
Feedback and difficult conversations is competency PL-2 in the EMA Competency Framework. The PL-2 unit of the Body of Knowledge goes further, including how to ask for feedback and how to take it when it's aimed at you.
The EMA-I questions on feedback describe a situation and ask what you would say next. See what EMA-I covers, or compare the three levels.