When Performance Management Stops Being About Performance

I once got into a difficult discussion with someone in HR about our engineering our role descriptions. They weren't very good. We had descriptions for each engineering level, but they were generic enough that they weren't particularly useful for evaluating performance. They contained the usual collection of phrases about technical competency, collaboration, ownership, communication, and impact. All good things, certainly, but there wasn't enough specificity for an engineer to look at the description and confidently understand what outstanding performance actually looked like.

That created a problem for me as a manager. I could tell an engineer I thought they were doing great work. I could tell them where I thought they were growing and where I wanted them to improve. What I couldn't always tell them, at least not with the confidence I wanted, was how that work would translate into their formal performance rating.

Twice a year, managers would get together and calibrate ratings. My evaluation of an engineer wasn't necessarily the evaluation they would ultimately receive. The committee could override it.

I hated this.

I've developed a pretty strong opinion about performance reviews over the years: they should be boring. Not meaningless. Not easy. Boring.

If you're struggling in your role, you should know you're struggling long before your performance review. If you're doing outstanding work, you should know that too. If you're close to a promotion but still have a couple of meaningful gaps, we should have been talking about those gaps for months - early enough that you can make the final push to get over the line. The annual review should mostly be the moment when we formalize a conversation we've already been having.

So I started pushing for clearer expectations. I wanted an engineer to be able to look at their role description and understand what meeting expectations looked like, what missing them looked like, and what genuinely exceptional performance looked like. I wanted managers and engineers to have something concrete enough that we could talk about performance throughout the year instead of trying to reconstruct it every six months.

During one of those conversations, someone in HR asked me a question that caught me completely off guard.

"How do you keep engineers from just going down the list and checking all of those boxes?"

I was beside myself. I remember thinking: Isn't that the fucking point?

Make the Boxes Hard Enough to Check

Obviously, I don't want an engineering career ladder that works like a punch card. Mentor three engineers. Lead two projects. Resolve five production incidents. Congratulations, you're a Staff Engineer. Engineering doesn't work that way. The work requires judgment, so evaluating the work requires judgment too.

"Demonstrates technical leadership" is too vague to be useful on its own, but we can describe what technical leadership tends to look like. Does this engineer identify important problems without waiting for someone to assign them? Do they make the engineers around them better? Can they navigate ambiguity? Do they improve technical decisions beyond the code they personally write? Do they recognize risk early? Can they bring other people along when they think something needs to change? Those aren't boxes that can be checked once. They're patterns of behavior that can be observed over time.

The goal isn't to eliminate judgment. The goal is to make the standard legible. If I define outstanding performance so loosely that every engineer on my team can effortlessly achieve it every year, I've probably set the bar too low. If I define it so aggressively that nobody ever reaches it, I've probably created an aspirational fantasy instead of a useful performance standard.

Somewhere between those extremes is a demanding but achievable definition of excellence. And I want every engineer on my team to know exactly where that bar is. More importantly, I want every one of them to have a legitimate shot at reaching it.

If I tell an engineer what exceptional performance looks like and they deliberately change how they work until they're consistently demonstrating those behaviors, they haven't gamed the system. The system worked.

That's what bothered me so much about the question from HR. The implication seemed to be that a good performance system needed some ambiguity in it, because otherwise too many engineers might figure out how to succeed.

It was clear we weren't really arguing about performance. We were arguing about money.

Performance and Compensation Are Different Problems

Performance ratings affected compensation, and compensation budgets were tight. Raises were generally pretty mediocre, somewhere around two percent or less by my estimate.

From that perspective, too many engineers receiving outstanding ratings created a problem. If a bunch of people were told they had dramatically exceeded expectations, there was a reasonable chance they would expect their compensation to reflect that. That's why HR wanted to push back tighter performance definitions.

If the organization defined outstanding performance too clearly, engineers might actually achieve it. If too many achieved it, managers might give out too many high ratings. If too many people got high ratings, the organization would have a compensation problem.

The whole thing was upside down.

I've worked at many startups. Often times that means raises simply aren't available. Sometimes the money isn't there. The company is trying to extend its runway, revenue hasn't caught up with hiring, another funding round hasn't closed, or there are simply more urgent places for the cash to go.

I don't love telling someone who had an outstanding year that I can't give them a raise, but I can have that conversation.

"We don't have the money" is an economic constraint.

"You weren't actually outstanding" is a judgment about someone's work.

Those aren't the same thing, and we shouldn't make the second one dishonest because the first one is uncomfortable.

Compensation management asks how much the company can afford to pay people, how compensation compares to the market, how a limited budget should be allocated, and what the business needs to do to retain its people.

Performance management should answer a different question: How well is this person doing their job?

Of course the two systems interact. It would be ridiculous to pretend otherwise. Someone who consistently performs at an exceptional level is going to expect that performance to matter eventually. If the company can't recognize it financially for long enough, that engineer may leave.

But that's useful information too.

Distorting performance ratings doesn't make the retention problem disappear. It just makes the conversation less honest.

There Are Other Ways to Reward Great Work

Money matters. I'm not going to pretend an interesting project and a pat on the back are equivalent to a meaningful raise. They're not.

But compensation isn't the only reason people do great work, and managers have more tools available to them than a salary adjustment. Some engineers want greater autonomy. Some want to own a difficult technical problem instead of being handed another ticket. Some want to lead. Some desperately do not want to lead, but would love the opportunity to become the person everyone trusts with the hardest technical problems.

One engineer may want a conference budget. Another may care about flexibility. Someone else may want mentorship, visibility with senior leadership, ownership of a new system, or the opportunity to move into a completely different part of the stack.

This is part of why 1:1s matter. I should know what the people who report to me actually want. When someone is doing outstanding work and money isn't available, I still have a responsibility to make that work consequential. I can't always give someone the reward they would choose if there were no constraints, but I can understand what motivates them and look for opportunities that move their career in that direction.

The alternative is teaching them that exceptional performance has a terrible return. People respond to incentives. Engineers certainly do. We spend our careers designing systems and then watching users discover exactly what behavior those systems reward.

Organizations aren't any different. If an engineer watches outstanding work get rewarded exactly the same as mediocre work, they're learning something about the system. If they watch promotions depend on vague criteria and twice-yearly arguments between managers who barely know their work, they're learning something. If they discover that taking on additional responsibility just earns them additional responsibility, they're learning something. Eventually, the organization shouldn't be surprised when they optimize accordingly.

Somebody Has to Be the Worst

I've seen an even more explicit version of this dysfunction: stack ranking. At one company I worked for, every engineering team was required to have someone who received a "within sight" rating (slightly lower than met expectations).

Think about what that means for a minute. If I have six engineers and all six are successfully performing the jobs I hired them to do, I still have to choose one and tell them they aren't. Their performance against the expectations of their role is no longer what determines their rating. Their performance relative to five other people who happened to land on the same team does. Those are completely different measurements.

This doesn't mean the distribution of ratings tells us nothing. If every engineer in a 500-person engineering organization is exceeding expectations every year, I'd start asking some hard questions about whether we've defined "exceeds expectations" appropriately. I'd ask the same questions if almost nobody could achieve it.

But a suspicious distribution is a reason to investigate the standard. It isn't a reason to manufacture the distribution you wanted in the first place.

Imagine I inherit a struggling engineering team. Over the next two years, we hire carefully. We improve our development practices. I spend time coaching people. Senior engineers mentor junior ones. We get better at reviewing code and designing systems. People who were struggling get help and improve. We remove chronic organizational obstacles that were making everyone's jobs harder.

Eventually I have six genuinely excellent engineers working together. That's supposed to be the goal. Under stack ranking, it doesn't matter. Somebody still has to lose.

In fact, the better I become at developing engineers and building a high-performing team, the more dishonest the performance process requires me to become. Eventually I'm identifying the least exceptional engineer on an exceptional team and sitting across from them while I explain why they "missed the mark."

At that point we no longer managing performance. We're managing a distribution.

Calibration Isn't the Enemy

I don't think calibration itself is a bad idea.

Managers are human, and we're inconsistent. One manager's "outstanding" can absolutely be another manager's "meets expectations." Some managers are naturally generous evaluators. Others hold people to standards that exist primarily in their own heads. New managers may not yet have enough organizational context to understand how expectations are being applied elsewhere. It's useful to get those managers into a room and compare notes.

If I'm rating everyone on my team at the highest possible level while every other manager is evaluating similar work differently, somebody should challenge me on that. Maybe I'm right. Maybe they're right. Maybe we've discovered that our career ladder is so vague that six managers have independently invented six different definitions of the same role. That's valuable information.

Calibration should help us apply a shared standard more consistently. It shouldn't become the standard. There's an important difference between a group of managers asking, "Are we evaluating similar performance similarly?" and asking, "Do we have too many high ratings?"

The first question is about fairness. The second is about the shape of a spreadsheet.

Underperformance Shouldn't Be a Surprise Either

Clear expectations aren't just for ambitious engineers trying to get promoted. They're arguably even more important when someone is struggling.

Managing an underperforming employee is one of the hardest parts of engineering leadership. Sometimes the problem is technical ability. Sometimes it's communication. Sometimes someone has taken on a role that isn't a good fit. Sometimes expectations changed around them. Sometimes life is happening outside of work in ways that are temporarily affecting what they're capable of doing. And sometimes someone simply isn't doing the job.

Whatever the reason, ambiguity makes almost all of those situations worse.

I never want someone's first clear indication that they're underperforming to arrive in a formal performance review. I certainly don't want it to arrive in a performance improvement plan. If there's a meaningful gap, we should already be talking about it:

• Here's what I expected.
• Here's what I'm seeing instead.
• Here are specific examples.
• Here's what I need to see change.
• Here's how I'm going to help.
• Let's talk again next week.

Then we keep talking.

Maybe they turn it around. I've seen people do that. Maybe we discover that I've misunderstood the situation and need to change something on my end. Maybe they ultimately can't meet the expectations of the role and we have to have a much harder conversation. But none of those outcomes should depend on surprising someone twice a year with a verdict from a committee.

The same system that gives a high-performing engineer agency over their growth gives a struggling engineer agency over their recovery. Clear expectations. Frequent feedback. Specific examples. A reasonable opportunity to improve. No surprises.

The Point Is Better Engineers

The thing I keep coming back to is remarkably simple. What is performance management actually for?

If it's primarily a mechanism for allocating a compensation budget, then vague criteria, forced distributions, and rating committees start to make a strange kind of sense. You're trying to divide a fixed pool of money without allowing too many people to make a claim on it. But I think that's an impoverished view of what performance management can do.

A good performance system changes behavior.

It tells engineers what the organization values. It gives managers a framework for coaching. It helps people recognize where they're weak. It gives ambitious engineers something concrete to work toward. It creates a common language for talking about growth. It makes promotions less mysterious and conversations about underperformance more fair. Most importantly, it gives people agency.

If seven people on my ten-person engineering team look at a demanding definition of exceptional performance, spend a year deliberately growing toward it, and actually get there, I don't have a performance-management problem. I have seven exceptional engineers. That's the fucking jackpot.

Maybe the company can't afford to give all seven of them a ten percent raise. That's a real problem, and somebody needs to solve it. But it's a different problem. The worst response is to build a performance system designed to make sure too many people never become exceptional in the first place.

I want engineers to know what great looks like. I want them to know what the next level looks like. I want them to understand where they stand today and what they can do tomorrow to get better.

And when we finally sit down for the formal performance review, I want the whole thing to feel almost boring.

We already had the important conversations.