A few years ago, I gave a performance review that I thought was honest and balanced. I covered the person’s genuine strengths, which were real and worth celebrating. I mentioned the areas for growth, but I kept the language careful — “continues to develop” rather than “struggles with,” a sentence about the opportunity to build more cross-functional relationships rather than a direct observation that the person was creating friction with peer teams. The review was true, technically. But it was soft in the places that mattered, and I knew it while I was writing it.
Six months later, that manager was surprised to learn that peers across the org found them difficult to work with. Not a little surprised — genuinely blindsided. And they had every right to be, because I had not told them clearly. I had gestured in the direction of the problem and let them infer, and what they inferred was “minor thing, not a priority.” Everything I wrote was technically true. But the thing that was actually going to determine their trajectory — the friction they were creating with peer teams — I had buried in such careful language that it didn’t register as the problem it was.
I’ve thought about this a lot since then, because I think the soft review is one of the most common failure modes in engineering management, and it’s seductive because it feels kind. It avoids the discomfort of the conversation. It preserves the relationship in the short term. And then there’s the fear that rarely gets named out loud: if I deliver a genuinely hard review to one of my strongest people, they might leave. So you sand down the edges, soften the language, make the friction sound like a minor development area rather than the real impediment it is — because the alternative feels like handing someone a reason to update their resume. The manager walks away feeling like they treated the person fairly. The problem is that the person walking away doesn’t have what they need to actually change anything, which means the outcome they’ll face — at the next review cycle, or in the calibration conversation, or when they’re being considered for a promotion — will feel like it came out of nowhere. And that’s not fair to them. It’s just fair to you.
The distinction I’ve had to get clear on in my own head is between honest and harsh. Honest feedback names the thing accurately and connects it to impact. Harsh feedback names the thing accurately and stops there, or adds a judgment about the person’s character rather than their behavior. A harsh review says “you’re not collaborative enough.” An honest one says “I’ve heard from three people on the cross-functional teams you work with that they feel cut out of decisions — that came up in two separate conversations with their managers, and it’s creating friction that affects your team’s ability to get things done. That’s something you need to address.” Same underlying observation, completely different in usefulness.
The test I use now, and I think about this explicitly when I’m writing reviews: if this person came to me in month seven and said “I thought I was on track — what did I miss?” could I look them in the eye and say I gave them what they needed? Not everything — I can’t predict every calibration outcome or every org change. But the core picture of how they’re doing and what stands between them and the next level? Did I tell them that clearly enough that they could actually act on it?
If the answer is no, the review is wrong. Not incomplete — wrong. Because the purpose of a review isn’t to document your observations for the record; it’s to give the person information they can use to grow. A review that’s technically accurate but functionally unusable hasn’t done the job.
The harder part is that honest feedback requires you to have a clear enough view of someone’s performance that you can describe the problem specifically. Vague feedback is often vague because the manager hasn’t done the work of forming a clear opinion, not just because they’re being diplomatic. “Could do more to develop influence” means nothing. “When you’re in the design review and you disagree with the direction, you go quiet rather than naming the concern — and then the issue comes up three weeks later in production, which we could have caught earlier” means something. Getting to that level of specificity requires paying close enough attention to someone’s work that you actually know what’s happening.
I try harder now than I used to. The instinct to soften a hard truth is strong — it masquerades as kindness, and every experienced manager fights it. But I think about that manager who was blindsided, and that’s usually enough to make me say the harder thing.