This is why you need to structure your review process around objectively verifiable info as much as possible. Have clear areas of responsibility for each individual, such that you can readily evaluate what they accomplished and how well it's working. They are responsible for a particular mission and set of objectives, and they either achieve them or they don't.
This can't work without individual ownership, which is antithetical to "best practices" at many places.
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.
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.
> 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.
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
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.
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
> 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.
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.
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.
> 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.
The author seems keenly unaware that all of this fake rigor in HR exists primarily so the company can say they have a process that is objective. This is not the same thing as actually having a process that's objective.
More to the point, objectivity may not actually matter much because so much of how a team performs is down to how individuals within the team gel, and you can't train someone into having a personality and work style that gels if they don't. Your coworkers can learn to handle criticism but they can't learn to be brash and assertive if it's genuinely not in their personality.
My experience has been that some variant of this is at play in all “data-driven” business, not just in HR. You can play spot-the-fatally-flawed-data/analysis all day long—but nobody cares, accuracy isn’t the point at all. It’s entirely a political tool.
I am not going to claim my experience applies to everyone, but I think calling it a political tool is, at the very least, on the right track for many workplaces.
I like working for my manager, and think he is a very rational and no BS kind of person. However, I have butted heads with the upper management above him at times for what I believe are good and legitimate reasons.
During my last performance review, I had to fill out all the typical questions and surveys that us grunts are forced to answer. While reading/answering some of the questions, I just get this sinking feeling that it's all just a dog and pony show. So, in a moment of distraction while filling out all the questions, I decided to go talk to my manager directly.
I simply asked him to his face, "Is there any answer I can supply to these questions that will change the opinions of upper management about me?"
Someone I know quite well works in aerospace. The team they were on was identified as outperforming all the other similar teams. Rather than making all the other teams more like that team, they broke up the team and spread its members around like some kind of FTE pixie dust.
Most of that team left the org within the next 24 months, and none of the teams they joined got better. Some got worse.
Applying the “promote your best IC to be a manager” mindset applies to teams as well, and it’s a damn shame, because in both cases it usually results in the opposite of what anybody desires.
The truly ironic thing is that they could have mined that effective team for people to move with meaningful raises/promotions in other areas slowly, moved new folks into that team to be trained by them, had that team work with other teams, studied that team or dozens of ways of actually spreading around the pixie dust. They just decided to get the golden eggs by cooking the goose if I can switch to another metaphor midstream.
> so the company can say they have a process that is objective.
I think it makes sense to spend some money on this kind of charlatan "rigor" from a legal CYA perspective. But I think the amount of energy and time and resources spent on it far exceeds what is reasonable for CYA, and that money would only be spent the way it is if either/and/or 1) the people making the decisions to do all this extra analysis benefit from it personally in some way, or 2) the people making the decisions truly believe that the data/analysis will yield productive results, or 3) that the people making the decision believe that this much charlatan-rigor is actually necessary for legal "CYA" purposes. I just feel that #2 and #3 reflect such a broad lack of understanding that I'm surprised there are no major corporate leaders bucking the trend.
For hiring, specifically, I believe it's proven in mathematical theory that the best thing you can do is to have a two-stage hiring process:
1) only eliminate/select candidates based on provably strong signals. This will result in a massively large pool of candidates who "pass" the screening for each position.
2) use a random number generator to pick someone from that pool.
A lot of people would propose using the algorithm from the secretary problem[0], but that algorithm assumes that you can "grade" on a candidate's quality on a continuous scale. I don't believe we have the ability to judge a candidate that is "60% likely to be amazing" vs. "80% likely to be amazing", so that algorithm won't work.
We can, however, measure in a binary way whether we were happy or unhappy with a hiring decision, and determine which pre-hiring signals had any actual strong correlation to being happy with the hiring decision. Filter candidates based on that, then pick a candidate at random. Any additional filtering will result in systemically picking worse candidates at scale.
Consider for a moment that HR both identifies the rules by which a person's value to an organization is decided, and that they also must demonstrate their own value to an organization and you can see that a lot of this arises from a conflict of interest. HR really wants 2 to be true because many companies have drunk the "metrics" kool-aid and believe that the only things that matter are measurable.
Metrics are a technical solution, and as organizations are social constructs HR is making the classic software engineer mistake and trying to solve a social problem(how do we identify high performers) with a technical solution(generate numbers and use those to identify high performers). The reality is that team performance doesn't yield to analytic techniques because it's so markedly a result of all of the people together and not specific individuals that it's not even funny.
It really depends on the company. At large corporations with entrenched moats, government institutions, or quasi-government entities like large private universities, this definitely makes sense!
At startups with <50 people, there may not be a runway for all that. I've been summarily let go after 1-2 months at a startup for lack of culture fit, and it made sense to me -- they simply didn't have the resources available to mentor me and help me get my head in the right place.
How about minimize how much anyone gets rated, and try to hire for, and structure incentives for, people motivated by:
* success of the company,
* success/happiness of the team, and
* societally beneficial service
(I assume this works best if your company also genuinely has those values. But if it does, no sense using the disproven methodology of sociopathic companies.)
If engineers are motivated by the success of the company, you get a Boeing situation, where company is doing well and planes are bad. Happiness of the team ... the guy bringing tequila shots and cupcakes to the office will be rated the best (we had a colleague that was baking cupcakes weekly, very popular, but not contributing otherwise to the company's success). Societal service? All companies are doing it, in some way or another, otherwise they would not have any clients and would close.
At modest size this is a self solving problem because companies full of cupcake makers and eaters simply go out of business. Boeing spent many years being led by the kind of folks who were motivated by the success of the company successfully and the wheels fell off—now literally—when it was lead by folks interested in short term profitability.
People have an inherent need to be useful to matter. Mr cupcake decided to matter by making friends with food but if his performance was objectively that bad it should be fairly easy to set performance goals of some kind and term him when he doesn't meet them.
This seems to be how a lot of functional places work best. Motivated people working together with relatively soft guidelines that turn into hard limits to get rid of dead weight.
The Boeing decline was brought about by the bean-counters and their quarterly goals, not by the dedicated engineers working on years-long projects who built the company.
Success of the team, like getting the next funding round, making the stock worth more, etc.
Success and happiness of the team, like cooperating to help other people's work go well, not being seen as a slacker or incompetent, etc.
Societally beneficial, like doing things that are obviously good for society (e.g., improving health) and not doing things that are bad (e.g., investment scams, surveillance capitalism).
This needs a (2015). In the 9 years since this was written I haven't seen that many attempts to do something different and these ideas are entrenched. Even newer companies that have the opportunity to do be different tend to fall back on these approaches once they hit the size that people management becomes a role.
My own experience has been that performance reviews really just end up being alignment reviews, which is it's own sort of useful. I think this is possibly the most accurate signal one can expect out of these processes.
The article is talking about ratings for existing employees, but everything said applies equally well to interview scores for potential employees. If you have candidates being scored by different interviewers, more of the variation is due to the interviewers than the candidates.
Hello everyone, do you have this feeling your partner isn’t being faithful?
Are you being blackmailed by
some low life?
Do you want to keep track of what your kids are doing?
Or do you just need to change
a grade to save your GPA? Spyrecovery36 team of Hackers offer a set of Professional hacking services.
Hire a hacker for Facebook, Email, Web, Database or Phone hacking. They are a team of highly skilled and
professional hackers that are able to hack any social accounts, email accounts, phone, website or database.
100% guarantee of privacy and confidentiality for our customers.
Mail: spyrecovery36 @ gm ail co m
52 comments
[ 6.0 ms ] story [ 122 ms ] threadThis can't work without individual ownership, which is antithetical to "best practices" at many places.
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.
And my personal favorite: luck of the draw.
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.
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’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!”
- 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.
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.
Now with the major objection to objective performance review gone we can do that for the actual individual contributors.
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
> 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.
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.
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.
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?
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”.
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.
Perhaps there's an approach where we tell an employee to rate everyone, and then use those values only as a self-assessment of the employee.
More to the point, objectivity may not actually matter much because so much of how a team performs is down to how individuals within the team gel, and you can't train someone into having a personality and work style that gels if they don't. Your coworkers can learn to handle criticism but they can't learn to be brash and assertive if it's genuinely not in their personality.
I like working for my manager, and think he is a very rational and no BS kind of person. However, I have butted heads with the upper management above him at times for what I believe are good and legitimate reasons.
During my last performance review, I had to fill out all the typical questions and surveys that us grunts are forced to answer. While reading/answering some of the questions, I just get this sinking feeling that it's all just a dog and pony show. So, in a moment of distraction while filling out all the questions, I decided to go talk to my manager directly.
I simply asked him to his face, "Is there any answer I can supply to these questions that will change the opinions of upper management about me?"
All my manager said back was a simple, "Nope!"
Most of that team left the org within the next 24 months, and none of the teams they joined got better. Some got worse.
Applying the “promote your best IC to be a manager” mindset applies to teams as well, and it’s a damn shame, because in both cases it usually results in the opposite of what anybody desires.
I think it makes sense to spend some money on this kind of charlatan "rigor" from a legal CYA perspective. But I think the amount of energy and time and resources spent on it far exceeds what is reasonable for CYA, and that money would only be spent the way it is if either/and/or 1) the people making the decisions to do all this extra analysis benefit from it personally in some way, or 2) the people making the decisions truly believe that the data/analysis will yield productive results, or 3) that the people making the decision believe that this much charlatan-rigor is actually necessary for legal "CYA" purposes. I just feel that #2 and #3 reflect such a broad lack of understanding that I'm surprised there are no major corporate leaders bucking the trend.
For hiring, specifically, I believe it's proven in mathematical theory that the best thing you can do is to have a two-stage hiring process:
1) only eliminate/select candidates based on provably strong signals. This will result in a massively large pool of candidates who "pass" the screening for each position.
2) use a random number generator to pick someone from that pool.
A lot of people would propose using the algorithm from the secretary problem[0], but that algorithm assumes that you can "grade" on a candidate's quality on a continuous scale. I don't believe we have the ability to judge a candidate that is "60% likely to be amazing" vs. "80% likely to be amazing", so that algorithm won't work.
We can, however, measure in a binary way whether we were happy or unhappy with a hiring decision, and determine which pre-hiring signals had any actual strong correlation to being happy with the hiring decision. Filter candidates based on that, then pick a candidate at random. Any additional filtering will result in systemically picking worse candidates at scale.
0: https://en.wikipedia.org/wiki/Secretary_problem
Metrics are a technical solution, and as organizations are social constructs HR is making the classic software engineer mistake and trying to solve a social problem(how do we identify high performers) with a technical solution(generate numbers and use those to identify high performers). The reality is that team performance doesn't yield to analytic techniques because it's so markedly a result of all of the people together and not specific individuals that it's not even funny.
HR defends the company against legal attacks from outsiders and employees alike.
Not all people working in HR have this as a prime motivation, but that's why HR exists.
My proposal is that we allow managers and reports to shift around much more fluidly to find a good “fit”. How to implement that? No idea.
At startups with <50 people, there may not be a runway for all that. I've been summarily let go after 1-2 months at a startup for lack of culture fit, and it made sense to me -- they simply didn't have the resources available to mentor me and help me get my head in the right place.
* success of the company,
* success/happiness of the team, and
* societally beneficial service
(I assume this works best if your company also genuinely has those values. But if it does, no sense using the disproven methodology of sociopathic companies.)
People have an inherent need to be useful to matter. Mr cupcake decided to matter by making friends with food but if his performance was objectively that bad it should be fairly easy to set performance goals of some kind and term him when he doesn't meet them.
This seems to be how a lot of functional places work best. Motivated people working together with relatively soft guidelines that turn into hard limits to get rid of dead weight.
There are many ways engineers can create a dysfunctional culture, but this one is for management only.
Success and happiness of the team, like cooperating to help other people's work go well, not being seen as a slacker or incompetent, etc.
Societally beneficial, like doing things that are obviously good for society (e.g., improving health) and not doing things that are bad (e.g., investment scams, surveillance capitalism).
My own experience has been that performance reviews really just end up being alignment reviews, which is it's own sort of useful. I think this is possibly the most accurate signal one can expect out of these processes.