Structuring the review around objectively verifiable data creates other problems.

What if there's a developer on the team who delivers 1/3rd the features as everyone else, but they offer such effective mentorship that their five teammates deliver features 2x faster? If you design your review process around objectively verifiable data, then it's almost certain to undervalue a developer who's great at mentorship because mentorship is hard to measure.

And it's not just mentorship. There are tons of contributions that seem pretty obviously beneficial but aren't objectively measurable: recognizing simpler ways of achieving business objectives, communicating clearly and effectively, being pleasant to be around, etc.

But if you go the other way and leave it up to pure human judgement, then you end up with promotion being based on favoritism, office politics, and irrational biases.

> But if you go the other way and leave it up to pure human judgement, then you end up with promotion being based on favoritism, office politics, and irrational biases.

And my personal favorite: luck of the draw.

People making lots of soft contributions like mentorship / leadership tend to be the kind of well-liked personable sorts who do well on non-objective assessments, which always manage to color evaluations even when you try to make them as objective as possible.

Not in my experience. I worked in 2 occasions with some older people (~ 65) that were the guru of their departments, very respected and listened. While people learned a lot from these 2 people, they were not too agreeable, but quite grumpy, I could say. That limited their careers, even if they were by far the best experts in their departments and overall the most valuable contributors, they were never considered for promotions.

On the other side, most well-liked people I met were professionally superficial at best, masters of talking and networking, but not delivering much at the end of the day. They were promoted first, so that the entire organization was full of these people promoting similar ones.

Same. The best people I ever worked with were grumpy graybeards (in spirit if not physically). Brusque is the kindest way to describe them. If you knew your shit, or at least demonstrated that you had exhausted your knowledge, they would help you.

That said, it isn’t _required_ for you to be a jerk; I’ve also worked with incredibly talented people who were generally kind. But they did not go out of their way to network and schmooze. IME, people who are concerned with what others think of them are the least accomplished.

I wonder if something about technical competence corresponds to being a jerk.

I’ve seen this happen again and again. Nice people become jerks when they become good at tech.

It doesn’t always happen. Plenty of compassionate tech wizards.

I suspect it’s due to the fact that being a jerk gets reactions quicker. “You messed this up, fix it like I tell you or I’ll ruin your reputation” gets more effect than “Let me show you how this works.”

I also suspect that programmers are often so lost in their heads, they don’t take good advice when it’s given.

I’ve been guilty of this. I’ve decided a problem is from X part of the stack, that when an expert in Y says to look in Y I’m like “but that doesn’t effect X!”

What I saw first hand: when someone really good is trying to help others there are usually 2 ways this can happen:

- they try their best, they need help, they ask for help, they get it

- they don't put any effort, they go to the expert with the most idiotic questions waiting for solutions to be served. The expert runs out of patience, becomes grumpy with these people

So the experts are not jerks. They are short on patience with super-lazy, super-incompetent people that waste their time.

Being an old grumpy guru is somewhat different from being a mentor, we're talking about different things.

> who delivers 1/3rd the features as everyone else, but they offer such effective mentorship that their five teammates deliver features 2x faster?

I haven't really encountered this. Generally speaking people who can teach others to be much more productive like that are unsurprisingly themselves, more productive.

This fictional person would be better suited to a people management or coaching role as a individual contractor they only achieve a third of the average.

Every team I've ever worked with (11) has had at least one person that would meet this archetype. Their team-based contribution usually wilts under the kind of individualized metrics being pushed for by some here and the team suffers as a result even if their own metrics get better.

Then do my second case, this person gets a different title so we can evaluate them differently.

Now with the major objection to objective performance review gone we can do that for the actual individual contributors.

I have no need to do that as I'm actually involved in my teams and don't need arbitrary numbers to see that someone is contributing. I'm fortunate that I have been able to avoid (or actively dodge) metric perverts in my career.

this type of person is exactly who we try to identify for staff and higher roles. They could be 20% or even 50% more productive as an individual, but if they raise everyone's game even 2% across 50 or more people they are producing far more value. The reality is they crush fewer tickets individually, and that's a good thing, but it gets perverted by a purely metrics-driven assessment.

My experience is that the best devs should not be crushing tickets. Just like the best surgeons have some of the worst survival rates, because they get the hardest patients, the best engineers should be working on the hardest problems the team faces. They should be spending a lot more time doing research, de-risking and clearing the way so that the rest of the team can crush the tickets.

Not just tickets. Lines of code (not just in main but in branches), deployments, runs of the automated build/test suite, lines of documentation written, number of responses in your company technical emergency slack channel, after hours pager incidents resolved, etc, etc

If the people near the top of those leader boards are near the top of the comp leaderboard your job is done as that makes sense by the numbers, if not you need a really good justification as to why* if you want to keep those literal top performers for long.

*or crossed fingers nobody discusses comp before you exit

These things are vanity metrics.

> Lines of code (not just in main but in branches)

IMO, the best devs can end up with negative LOCs per measurement period. Neophytes will never have negative LOCs. Mediocre devs who copy and paste a lot can have really high LOCs.

> lines of documentation written

And the more documentation you have the more out of sync it is with reality.

The people who would be confused by these metrics in the way you describe aren't going to do any better without them.

Sometimes you get the cranky old guy archetype who doesn't really get much done but is really good at making sure the kids don't make any really dumb mistakes, which is its own kind of value

This is pretty much impossible above a senior IC level, where job responsibilities are focused on coordination, collaboration and other "glue". The responsibilities are going to constantly change over time, and be different for every individual. Trying to define & document this is a fool's errand. I think you're way better served to set broader objectives that are not SMART goals and then continually discuss, identify and update concrete delvierables that serve the spirit of the overal goal. This helps stop actions from being irellevant or misaligned with changing priorities, and provides a body of hard evidence for evaluating performance. I encourage everyone I manage to spend a few minutes a week capturing all their accomplishments, specifically the "soft" ones that don't have artifacts and will be forgotten (by both me and the mployee), and take an initial stab at categorizing the item against our corporate values (because I know that's what their formal review will look like). I had someone (who is a high performer) turn their multi-hour review preparation cycle into a 20-minute cut&paste operation.

Once you get above a certain level sure, it's not mostly about IC metrics anymore. But that doesn't mean you can't make them objective. If a person has a set of defined responsibilities, they either delivered on them, or they didn't, and you should be able to judge that relatively objectively. And if those responsibilities can't be clearly defined, or are constantly changing, that's a signal of organizational dysfunction. I will agree that if you're in an org like that, it will be difficult to judge people's accomplishments objectively.

What objective measurements are good for engineering?

You can come up with superficial ones: lines of code written, tickets closed, hours seen in office, but I doubt those are strongly associated with effectiveness. Everyone in has probably had weeks where they “did nothing” because they were working on a tricky problem or doing work outside of what was quantified.

Don't confuse objective with easily quantified.

Did they ship the features they were responsible for? Did those features turn out well, with a low defect rate? Did they promptly address bugs? Any manager paying attention can answer these questions pretty objectively.

> Don't confuse objective with easily quantified.

You say this and then go on to do the exact opposite in

> Did those features turn out well, with a low defect rate?

And likely in this

> Did they ship the features they were responsible for?

So which is it?

> Did those features turn out well, with a low defect rate?

Is the objective measure of “well” a low defect rate? Because it sounds like you’re leaving a substantial amount of the value of an experienced employee on the table if your measure is “does it do exactly what we asked for it to do” rather than “does it solve our problems”.

It's a flawed premise, the whole thing, worthless. In like any science, even half-baked science, there's a case and a control. Every drug, treatment, test you're given by the doctor... there was a phase trial, cases and controls, outcomes, statistics, etc

Here we're saying "okay, our case is n=1 samples, no control, we're going to need to lean on our gestalt experience and knowledge based on the virtues of this company saying we're good at managing and/or our HR credentials" (this type of thinking also exists in medicine and is equally unsettling - usually wielded by people with experience AND power so it's difficult to disrupt due to the latter)

The lack of control means you can't compare Peter to Paul because maybe Peter likes to stick his neck out and/or take one for the team as a show of teamwork and humility, maybe Paul is cautious and wants to maximize revenue from this position and loves to play politics. Peter is willing to go the extra mile for the company, but Paul will be the one with the perfect record. Now, if there were decent controls for either, they would show Peter is outperforming a control given challenging tasks, and Paul is underperforming by minimizing work done.