Being right about the problem is a reliable way to become the problem.
A peer’s low performance keeps blocking your work, so you do the responsible thing and raise it with the manager who owns the problem. Weeks later nothing about the peer has changed, but something about you has. The manager has turned the performance issue into a relationship issue: the peer isn’t underperforming, the two of you just “don’t get along,” and working on the relationship is now your job. Will Larson describes the result:
By attempting to drive accountability in their peer, the main character has blocked their own progress (“they’re just hard to work with”) without accomplishing anything.
The feedback was correct, so what went wrong? Most of us assume that correct feedback, reasonably delivered, should land, and that when it doesn’t, the receiver failed. Larson’s answer is less flattering: Organizations can only absorb so much improvement at a given time before they reject the person providing the feedback. Being rejected while trying to help is painful, but it is predictable, and failing to predict it is a failure of the person giving the feedback.
What the manager heard
You thought you were bringing the manager a new problem. But the manager almost certainly knew already and had chosen not to act, so what you were really doing was holding them accountable for not solving a known problem. Holding someone more senior accountable for a known failure almost always ends poorly. Your escalation wasn’t information to them; it was an implicit accusation, and recasting it as a personality clash is the easiest way to deflect one.
A useful picture is a feedback pipe between any two people, with a fixed bandwidth. A trusted mentor or long-time collaborator has a wide pipe and can be blunt. A new colleague or someone in conflict with you has a narrow one, and some pipes are blocked entirely. The width is set mostly by trust, which decides how much of a message survives the trip. Push correct feedback through a pipe too narrow to carry it and you don’t improve anything; you become hard to work with.
Two things narrow the pipe faster than people expect. One is rank. The less senior you are perceived to be, the more you are expected to have strong rationale before delivering feedback. A VP can say “I don’t love this direction” and the team pivots, while a junior engineer saying the same thing needs data, precedent, and political cover. That is unfair, and ignoring it doesn’t make you principled, only ineffective. The other is commentary, opinion about a situation expressed to the room, as opposed to feedback, which is directed at someone with the intent to change what they do. Saying “this codebase is a mess” in a team meeting performs frustration and spends the credibility you would need to change anything.
The absorption rate
Even through a wide pipe, with careful delivery, organizations have a maximum absorption rate. Push more improvement than the system can metabolize and it rejects you, not the improvement. That is why the correctness of feedback is nearly irrelevant to whether it produces change, and why the strategically correct move is sometimes to hold back feedback that is right: delivering it now uses up bandwidth you will need for something that matters more later. The messenger’s credibility is the message’s delivery vehicle, and burning the vehicle to send one package means no future deliveries.
The same limit changes what useful feedback looks like. Work environments change slowly. It benefits your team more to give them feedback about how they can succeed in their current environment than to agree with them about how the environment fails to support them. The first is actionable. The second is commentary, however accurate.
The receiver’s half
None of this makes receivers blameless. Some people reject feedback by attacking its delivery: the tone was wrong, the timing was wrong, the context was wrong. Larson again:
They become feedback lawyers who fixate on the weakness in how feedback was delivered rather than trying to understand the content within the feedback itself.
Each objection can be technically valid while working as a refusal to hear. But a giver can’t fix it from outside. You control what you say and when, not whether it is received.
So go back to the escalation. Once the manager had filed you as hard to work with, the accuracy of your complaint stopped mattering. What might have worked was slower: building the pipe with that manager before you needed it, and spending your credibility on the one change the system could absorb rather than on being right about all of them. That is less satisfying, because the thing you most want to say is usually commentary, and commentary is the most expensive way to change nothing.
References:
- Will Larson, Hard to Work With
- Will Larson, Constraints on Giving Feedback