markdown guide
 

I don't have much to offer other than the review should happen all year long via 1:1's and quarterly discussions. This way there's no surprise at the end of the year. And both sides should keep notes throughout the year to remove any recency bias around the annual checkin.

 

We don't have performance-reviews and salary-negotiations are usually tied to moving from junior to mid-level to senior, except the yearly few % organic salary-increase to balance inflation.

One that doesn't suck for me would be a constructive feedback-meeting, with your lead, where they try to get a good picture of your impact and behaviour within your team and company beforehand.

This of course goes both ways, so you as employee should also review your companies performance and give feedback accordingly. Is this a seller's market or what.

 

We don't have performance-reviews and salary-negotiations are usually tied to moving from junior to mid-level to senior, except the yearly few % organic salary-increase to balance inflation.

Interesting. What are the criteria for moving from junior to mid to senior?

This of course goes both ways, so you as employee should also review your companies performance and give feedback accordingly.

I like this a lot!

 

With a sufficiently skilled manager, they do not. In my experience, however, around only 1 in 10 development managers can be called a skilled manager.

 

IYHO what makes those 1 in 10 performance reviews not suck?

 

To be clear, 1-in-10 managers not 1-in-10 performance reviews. The majority of performance reviews are missed opportunities at best and emotionally scaring at worse.

How a 1-in-10 manager makes a performance review not suck is difficult to summarize without using platitudes, so I'm going to resist making a list.

The way I've coached managers is by doing mock sessions where they play the part of a hypothetical employee, and I demonstrate how I would handle giving them a performance review. I let them craft the scenario of the type of employee I'm reviewing, which can be anything from an extremely high performer to someone you know you need to fire. The feedback I tend to get is, "Wow - you phrased that really well," which is not surprising as the entire game is persuasive phrasing.

Ultimately, I want a better employee after a performance review, so the goal is to help them reach the next level. If the employee leaves the review disillusioned, demoralized, or they start thinking about finding a new job, then I've failed to create a better employee, and therefore failed to give an effective performance review.

BTW, this question is contextualized as "performance reviews", not giving someone feedback. Performance reviews tend to have rules that have been blessed by the board of directors and enforce via HR. Giving feedback is something humans do when we want to help someone improve.

Thanks for the thoughtful reply.

Is there something about the performance review process itself that can help it not suck?

I'm having a hard time explaining exactly what I mean... things like the criteria employees are reviewed on, the structure of the review documents/procedures, frequency of the review, etc. Sort of like, the nuts and bolts of the process itself. Or is it all about the reviewer's approach?

We risk entering dark territories should we venture forward, but venture forward we must.

Capitalism is based on many ideas, with one of it's most important being fungible labor, i.e. people who can be replaced at will without a significant impact on the business. This has the implication that in order to build a functioning corporation with a multi-decade lifespan, you must not give a lot of importance to who fills a role, just that the role is filled. This then results in responsible corporate managers looking at their organizations as being made of up roles, not people. How then, do we define a role?

The industrial era gave corporate managers an extremely convenient tool for managing all aspects of the business: spreadsheets. By defining attributes to measure, and measuring those attributes over time, problems can be identified, and optimizations can be applied. For example, when maximizing the number of cars that can be produced on an assembly line with all-human labor, using spreadsheets as a means to manage people works very well, as the task of each worker must be standardized to maintain quality, i.e., two people who weld sheet metal both have a standardized skill set that is only differentiated by quality. Provided there are quality standards, anyone who welds sheet metal can be exchanged for anyone else that welds sheet metal. If workers are expected to weld 1000 pieces of metal a day, and a particular worker drops to 999 pieces of metal, their performance is below the required level and they must either be improved or replaced.

Fast forward to the information age driven by rapidly evolving technology, and exactly the same methods that were used to manage people on factory floors are used to manage people who write software. Now suddenly performance reviews are far more awkward. How does one equate pieces of sheet metal with writing software? For a while, lines of code were used, but it was slowly realized to be a false equivalency thanks to code's characteristic of lines not having a strong correlation to value. Today, we try to use "features", "bugs", and "tests" as units of measure, but so far those still don't give us something as good as pieces of sheet metal welded per day. How then do we perform performance reviews when their are no clear measures of performance? We do it by forcing a manager and an employee to participate in a ceremony serving no other purpose than to preserve a traditional yet now-ineffective practice from a bygone era.

Why then don't we change? Why indeed. It has been said that it is impossible to get someone to understand something if their job depends on them not understanding it. If a manager cannot manage using performance metrics, what then is the value of a manager? Why would a manager acknowledge that performance reviews don't work if that could mean they are out of a job? As so, the practice continues.

Classic DEV Post from Dec 12 '18

Will Java Trend Towards Obscurity?

I'm forking another conversation: ...

Ryan profile image
I've got this store-bought way of saying that I'm OK.

Need a change?

dev.to now has dark mode.

Go to the "misc" section of your settings and select night theme ❀️