The Curve Needed a Bottom. I Refused to Supply One.

August 11, 2026

The Curve Needed a Bottom. I Refused to Supply One.

At one company I worked for, calibration season arrived the way it always does: a room, a spreadsheet, and a policy that says someone has to land below meets expectations, because a curve needs a bottom. My group had just closed out double-digit growth. Other groups in the same division had lost money, market conditions, not effort. HR's position was that fairness meant someone from my group needed the same low rating regardless.

I refused the argument at the group level first: my team had already proven, with real numbers tied to business outcomes, that this was not a case of underperformance. Whoever ran that room was not moved by that alone, and pushed the request down a level: fine, then pick individuals inside your own group who did not do as much as the others. My team's growth was not one person's work. It was the product of how the whole group operated together, the kind of result you cannot honestly slice into a ranking of who deserves it least.

Losing that argument was not an abstract risk. It meant going back to my own team and delivering a rating I could not defend. These were people I had spent the year telling they were doing well; I would have to tell them they would not get a full raise or bonus, because a curve needed a bottom and someone had been assigned to it. It meant helping the people who received that message find somewhere else to work, because staying somewhere that would do that to them, on purpose, with no honest reason attached, was not something I could recommend to anyone I actually cared about. I sat with that choice for real: if I lost the argument, I was not going to deliver that message to any member of my team. I would exit the company before I would carry it to them. Losing the argument also meant I would no longer be there to protect them going forward, and I felt the full weight of that trade before I ever knew which way it would go.

Every technical leader who has been subjected to a calibration has felt some version of this pressure, even when the specifics are milder: an org-wide rating curve that has nothing to do with what your team actually did, and a quiet expectation that you will make the math work anyway. The version everyone repeats to justify it sounds responsible: in a tight-budget year, someone has to enforce consistent, comparable ratings across teams. That is what a forced distribution is for. It keeps compensation disciplined company-wide and prevents rating inflation. A manager who resists it because "my team is different" is exactly the manager the policy exists to check.

Here is what that framing never says out loud. A rating system exists to answer one question: did this person do the job well? A forced distribution needs an answer to a different question entirely: how do we keep company-wide compensation inside a budget line? Rather than building an honest mechanism for the second question, the organization runs it through the first system's vocabulary. Below expectations gets used to mean your group's growth number was lower than another group's, or worse, someone in a group that grew still had to be picked anyway, while it still sounds, to the person receiving it, like a verdict on them personally. The manager who accepts this without pushing back becomes the transmission point: they take a company-level budget decision and hand it to an individual as if it were a personal one.

The team member has no way to tell the difference between real feedback and budget theater going forward. Every rating after that, even an accurate one, carries a permanent asterisk. Once a team learns that hard work does not reliably determine what they are told about their own performance, the ones with the most options leave first. They finally understood what the rating was actually measuring.

The leaders who catch this before it reaches their team are not braver than the ones who don't. They walked into the room already holding the one thing that makes the refusal possible.

The evidence tying your team's work directly to business value has to be ready before you walk into that room. Resume material filed away for later does you no good in the moment it matters. It is the tool that proves exactly where the substitution is happening: a demonstrable gap between what the rating claims to measure and what it is actually measuring, something no feeling or values objection can establish on its own. This is Signal Staging: the same function that decides which incoming signal is real and which one needs to be held at the boundary, at its hardest edge. Sometimes the job means refusing to let a signal through at all, rather than translating it for your team, because passing it along would corrupt the one thing the team actually needs to trust: that a rating still means what it says. If you lose that fight and the message still has to be delivered, deliver it as what it actually is, never repackaged in whatever language keeps the company comfortable. Your team deserves the truth about where a number came from, even when that truth is that it was never about them.

Think about the last time you delivered a rating, a cut, or a piece of hard news to your team that came from above. Could you have proven, with real evidence, exactly what it was actually measuring? Or did you deliver it in the company's language because you had never actually checked?

I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS: http://TheLeadershipOSBook.com


I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS: http://TheLeadershipOSBook.com

Anthony S. Jackson

Anthony S. Jackson

Anthony S. Jackson has spent 30 years inside technical organizations. He is the author of the Architecture Protocol Series: three books on the structural problems technical leaders were never told they would face. He writes the LeadershipOS™ Inner Circle, a monthly printed newsletter for CTOs and engineering managers who design teams that hold under pressure.

LinkedIn logo icon
Back to Blog