Aka a blueprint to turn your efficient company into a bloated office politics obsessed enterprise.
I have never seen a company with such a structured review process not have the review process gamed by political players. Especially peer review, that is just asking for gaming.
Annual or semiannual reviews are way way too infrequent. Just pull up with the employee when any problems occur. Or have weekly one on ones (props to the article for mentioning this). Just don't what 5 months to ding an employee for an event they no longer remember.
Seen this as well. Does somebody in management really expect leadership roles to sit down every 6 to 12 months, discuss everything their employees have done, and do it objectively? That's a fast track to giving everybody but the absolute worst a 5 out of 5 every time.
I'm a big proponent of the one-on-one approach, and giving feedback as needed. I am curious, however, typically the review cycle is correlated with the raise and bonus cycle. How would you go about handling that process with the data points that the review cycle provides, however artificial they may be.
I would ask why is there a set cycle for raises? If an employee is valuable enough for a raise why wait and risk a competitor poaching them before the cycle comes around?
That may sound far fetched but my current company has a very rigid and well known cycle and I swear that recruiters know about it. I get way more recruiter calls leading up to raises than afterwards.
Good on you for noticing that the annual review data is artificial. I suspect that is why these processes exist. Companies want to base there decisions on data and don't care if that data is meaningless.
One item the author should add is "Ask employees and managers one question: Does our performance management process provide value to you? What could be done better?".
It seems this stuff always gets cooked up by somebody who never has to go through the process themselves.
I do prefer to have formal performance reviews tied to anniversary dates instead of a company wide performance/merit increase cycle. It's almost impossible to give thoughtful reviews to 10-20 people at one time.
Having been a part of large organizations that do it both ways, it is very hard to give objective feedback to large group of staff if it isn't done at the same time. Eventually everyone that isn't a total screw-up earns the "top box" and the performance review becomes meaningless. If everyone is done at the same time and you want to reward your top 10%, the managers are forced to identify who the 10% really are.
Is your intention to churn the bottom 90% of your organization through inflation and greener pastures elsewhere?
It does seem generally the case that if you're not a total screw-up, you expect and can get periodic increases in compensation and responsibility. To deny this to someone is to declare them a total screw-up, because you're signaling to them that they ought to leave for another company or field where they won't have already peaked.
Staying in the same role and salary you had when you first entered the workforce doesn't seem like something we can realistically expect from 90% of software engineers.
So I'm not sure it's terribly broken just because most people are getting promote-able ratings.
Ratings are discussed in this article. But not specifically pro/con are rankings, sometimes controversial. What's HN's take on rankings?
To clarify: I mean ranking employees within or among certain teams. In companies that produce rankings, I think the rankings often supersede the ratings when used as input to raises/bonuses/etc.
My opinion is that they are the worst idea ever created. They incentivize infighting and undercutting each other. They lead to situations where everyone on your team is a top-notch performer but you have to cut someone, so you fire someone who's doing a great job. Or the reverse, everyone on your team is a complete fuck-up, but you have to give bonuses to the top 10% or whatever, so you reward people who are doing a terrible job. Nobody I know who has been involved with them (including the managers who have to do cutting and bonus-giving) thinks they're a good idea.
One part that seems missing: Why are you trying to start a performance management system?
Do you suddenly have too many people and are looking to promote the good ones and get rid of the bad ones? Are people not communicating effectively? Are you trying to figure out what people are actually doing with their time? Trying to figure out who needs to get raises?
Different orgs at different stages have different problems.
Seems like implementing a solution without understanding the problem, and that never goes well.
14 comments
[ 2.5 ms ] story [ 38.0 ms ] threadI have never seen a company with such a structured review process not have the review process gamed by political players. Especially peer review, that is just asking for gaming.
Annual or semiannual reviews are way way too infrequent. Just pull up with the employee when any problems occur. Or have weekly one on ones (props to the article for mentioning this). Just don't what 5 months to ding an employee for an event they no longer remember.
I'm a big proponent of the one-on-one approach, and giving feedback as needed. I am curious, however, typically the review cycle is correlated with the raise and bonus cycle. How would you go about handling that process with the data points that the review cycle provides, however artificial they may be.
That may sound far fetched but my current company has a very rigid and well known cycle and I swear that recruiters know about it. I get way more recruiter calls leading up to raises than afterwards.
Good on you for noticing that the annual review data is artificial. I suspect that is why these processes exist. Companies want to base there decisions on data and don't care if that data is meaningless.
It seems this stuff always gets cooked up by somebody who never has to go through the process themselves.
It does seem generally the case that if you're not a total screw-up, you expect and can get periodic increases in compensation and responsibility. To deny this to someone is to declare them a total screw-up, because you're signaling to them that they ought to leave for another company or field where they won't have already peaked.
Staying in the same role and salary you had when you first entered the workforce doesn't seem like something we can realistically expect from 90% of software engineers.
So I'm not sure it's terribly broken just because most people are getting promote-able ratings.
To clarify: I mean ranking employees within or among certain teams. In companies that produce rankings, I think the rankings often supersede the ratings when used as input to raises/bonuses/etc.
Do you suddenly have too many people and are looking to promote the good ones and get rid of the bad ones? Are people not communicating effectively? Are you trying to figure out what people are actually doing with their time? Trying to figure out who needs to get raises?
Different orgs at different stages have different problems. Seems like implementing a solution without understanding the problem, and that never goes well.