The last time I ran a forced ranking cycle, I spent a Tuesday afternoon arguing with two other directors about whether a payments engineer who had spent six months rebuilding our reconciliation pipeline should be slotted into the bottom 15 percent because his shipping velocity looked slow on a spreadsheet. He had prevented a class of settlement errors that would have cost us real money and real regulatory attention. On paper he looked like a laggard. In the room, everyone knew he was one of the most valuable people we had. That was the moment the whole exercise stopped making sense to me.
I ran stack rankings, in one form or another, for about four years. Then I stopped, deliberately, and I have not gone back. This is not a management-trend hot take. It is what I actually watched happen to my teams, and why I think forced distribution is a bad fit for the kind of engineering work that fintech demands.
What a ranking actually measures
The theory behind stack ranking is tidy. You line people up, reward the top slice, manage out the bottom slice, and over time the average quality of the team rises. Natural selection with a compensation budget attached. The problem is that it only works if your ranking signal is clean, and in engineering it almost never is.
What a ranking measures, in practice, is a manager's ability to construct a persuasive narrative during calibration. The engineer whose manager tells the best story wins. That is a real skill, but it is not the skill I am trying to reward. I watched genuinely excellent engineers land in the middle of the pack because their manager was junior, or conflict-averse, or simply bad at the theater of advocacy. Meanwhile a competent-but-loud performer got a top slot because someone in the room went to bat for them harder.
Once I understood that the ranking was measuring advocacy quality as much as engineering quality, I could not un-see it. Every subsequent cycle just confirmed it.
The reconciliation engineer problem
Fintech has a specific structural issue with productivity metrics, and I have started calling it the reconciliation engineer problem, after that Tuesday afternoon. Our most important work is often invisible when it goes well. Nobody writes a celebratory Slack post about the fraud rule that quietly stopped firing false positives, or the idempotency key that prevented a double-charge during a retry storm. The wins are the absence of incidents.
Forced ranking systematically underweights this kind of work because it has no positive signal attached. You cannot point at a dashboard and say "look at all the settlement breaks that didn't happen." So the engineers doing the load-bearing, preventive, deeply unglamorous work of keeping money movement correct tend to rank below the ones building shiny new features that get demoed to the board.
In a regulated payments business, the person who prevents the incident is worth more than the person who ships the feature. A ranking system that cannot see prevention is optimizing for the wrong thing.
I am not saying feature builders don't matter. Of course they do. But when your scoring model can only see the visible half of the work, you are quietly teaching your best defensive players that defense doesn't pay. In our world, that is dangerous.
The collaboration tax nobody talks about
Here is the part that convinced me the damage was structural and not just cosmetic. A forced curve turns your teammates into your competitors for a fixed pool of top ratings. It is zero-sum by design. If there are three top slots on a team of fifteen, then helping a peer look good literally lowers your own odds.
Most engineers are decent people and will not consciously sabotage each other. But incentives work at the margin, and the margins are where the damage accumulates. I saw it in small, deniable ways:
- Senior engineers becoming quietly reluctant to spend a full day unblocking a struggling teammate, because that day didn't show up in their own delivery numbers.
- People hoarding the interesting, high-visibility projects and steering the grunt work toward others.
- Code reviews getting terser and more adversarial around review season, then loosening up again once ratings were locked.
- A subtle drop in the willingness to say "I don't know" or "I need help," because vulnerability during a ranking cycle feels like handing your competitor ammunition.
None of that is a firing offense. All of it is corrosive. And it hits hardest exactly when you most need people pulling together, which in payments tends to be during a nasty production incident at two in the morning.
Calibration theater and the illusion of rigor
Defenders of stack ranking love the calibration meeting. The pitch is that getting a room of managers together to compare notes removes individual bias and produces a fair, consistent result. In my experience it does the opposite while feeling more rigorous, which is the worst of both worlds.
What actually happens in calibration is horse-trading. "I'll move my person down if you move yours up." Anchoring on whoever spoke first. Recency bias toward whatever shipped in the last six weeks. A strong director can drag their whole team up the curve through sheer force of personality, and a quiet one cannot. The meeting adds a veneer of objectivity to a process that is still mostly vibes, except now the vibes are laundered through a spreadsheet and four hours of argument.
I timed it once. Between manager prep, the calibration sessions themselves, the pre-meetings to align on the meetings, and the follow-up delivery of ratings, a single cycle consumed something like two full working weeks of senior engineering leadership time, twice a year. That is a genuinely expensive way to produce a signal I had already stopped trusting.
The attrition I didn't want
The bottom-slice logic assumes the people who land there are your weakest, and that losing them improves the team. Sometimes that was true. More often the people who left after a mediocre ranking were not the weakest. They were the ones with the best outside options, which is a very different group.
A strong mid-level engineer who gets told they are in the middle of the pack, when they know full well they carried a hard project, does not shrug and try harder. They update their LinkedIn. The engineer who genuinely was struggling, on the other hand, often stays, because they have fewer places to go. So the curve slowly filters for the opposite of what it promises: it retains the immobile and repels the mobile. Over a couple of cycles that becomes a real quality problem, and it is entirely self-inflicted.
I lost a payments-platform lead this way. Ranked fine, not spectacular, in a year where she had untangled a genuinely gnarly ledger migration. She read the signal correctly as "you are replaceable" and took an offer elsewhere within the quarter. Replacing her cost me nine months and a chunk of institutional knowledge that never fully came back.
What I do instead
Killing a process is easy. Replacing it is the hard part, and I want to be honest that what I moved to is more work for managers, not less. There is no free lunch here.
I use an absolute bar instead of a relative curve. Every engineer is measured against a written expectation for their level, and it is entirely possible for a whole team to clear the bar, or for most of them to. If I have hired well, that should happen often. When it does, I want to celebrate it, not manufacture a bottom slice to satisfy a distribution. The obvious objection is grade inflation, and it is a fair one. My answer: I would rather police the bar directly, by keeping level expectations sharp and pushing back on soft promotion cases, than outsource that discipline to a curve that also poisons collaboration as a side effect.
For compensation I decoupled the money from the ranking. Pay tracks level, market data, and scope, adjusted for a small number of genuinely exceptional contributions that I can name specifically. Performance management for real underperformance happens continuously and directly, through actual conversations, not once a year through a forced slot. If someone is below the bar, they should hear it in March, not discover it in a December calibration outcome.
But what about real underperformers?
The strongest argument for stack ranking is that it forces managers to confront poor performance instead of avoiding it. I take this seriously, because it is true that plenty of managers will duck a hard conversation if the system lets them. Conflict avoidance is the default human setting.
But the forced curve is a clumsy fix for that. It makes managers confront a relative position, not an absolute problem. It will happily push a perfectly adequate engineer into the danger zone in a strong year, and it will let a genuine underperformer coast in a weak one. If your actual goal is to deal with underperformance, then deal with it directly: clear expectations, early feedback, a documented plan, and the willingness to follow through. That is harder and less automatable than a curve, and it is also the actual job. I would rather train my managers to do the hard thing than hand them a mechanism that does an adjacent, easier, wrong thing and calls it courage.
What I gave up, honestly
I do not want to pretend this was pure upside. Getting rid of the curve cost me some things, and I would be lying if I said the trade was free.
Cross-team comparability got fuzzier. It is genuinely harder to answer "is this team's bar as high as that team's" without a common distribution to point at, and I now spend more energy calibrating expectations by hand across skip-levels. I also lost a convenient piece of political cover. When a curve told me someone was in the bottom bucket, I could gesture at the process during a hard conversation. Now the judgment is visibly mine, which is more uncomfortable and, I think, more honest. And a small number of ambitious engineers actually liked the ranking, because they were confident of winning it, and they missed the explicit scoreboard. I decided I was fine losing that particular motivator.
Conclusion
If I have one piece of advice for a leader still running the curve, it is this: ask who the process is really protecting. A stack ranking is a management convenience dressed up as objectivity. It moves the discomfort of judging people off the manager's shoulders and onto a spreadsheet, and in exchange it teaches your team that helping each other is a bad bet. In a business where money movement has to be correct, and where the best work is often the incident that never happened, that is a trade I am no longer willing to make. The judgment is supposed to be mine. I would rather own it in daylight than launder it through a curve and pretend the spreadsheet decided.