Most technical feedback fails not because it's wrong, but because of how it's delivered. The engineer hears criticism of themselves, not of the code. After that, the conversation is over — they're defending, not learning.
I've made this mistake. Early in leading teams, I thought being direct about code quality was the same as being clear. It isn't. Directness without context lands as judgement. And once someone feels judged, they stop hearing the substance of what you're saying.
Separate The Code From The Person
The most useful reframe I've found is to talk about the code as a shared artifact, not a reflection of the person who wrote it. 'This service has too many responsibilities' is a different conversation than 'you designed this service wrong.' The first invites collaboration. The second invites defensiveness.
This sounds obvious. It's easy to forget in practice, especially during code reviews when you're moving fast and the problems feel obvious. The habit is worth building deliberately.
Context Before Correction
Before giving feedback, I try to understand why the code is the way it is. Sometimes the 'wrong' decision was made under a deadline. Sometimes it was a deliberate trade-off that wasn't documented. Sometimes the engineer simply didn't know a better pattern existed — which is a completely different problem than knowing and not caring.
Asking 'what were you optimising for here?' before saying 'this isn't the right approach' changes the dynamic. You might learn something. You might find out the feedback you were about to give doesn't apply. And at minimum, the engineer feels like you're trying to understand before you're trying to correct.
The Feedback Nobody Gives
Positive feedback on specific technical decisions is underused. Not 'good job' — that's noise. But 'the way you handled the retry logic here is exactly right, here's why' is teaching and recognition at the same time. It tells the engineer what good looks like in concrete terms, which is far more useful than a general performance review.
People repeat what they're recognised for. If the only feedback engineers receive is corrective, they learn what not to do but not what to do more of. Both matter.
When Feedback Doesn't Work
Sometimes feedback doesn't land because the relationship isn't there yet. An engineer who doesn't trust your judgement won't take your technical criticism seriously, regardless of whether you're right. The credibility has to be earned first — through shared work, through being right about things that mattered, through showing that you're invested in their growth and not just in the quality of the output.
This is the part of technical leadership that doesn't feel like technical leadership. It's slow, it's relational, and it doesn't show up in any metric. But it's what makes everything else possible.