As I sat listening to my boss drone on about aligning my performance with company objectives, I couldn't shake the feeling of dread that came over me. The performance review felt like a tedious and unproductive exercise, with no acknowledgment of my hard work, achievements or well-being. I left the meeting feeling disheartened and began considering leaving the company altogether.

However, fate had other plans for me, and as I progressed in my career from one organization to another, I was quickly promoted to engineering manager.

Despite my reservations, I requested the promotion with the condition that I redesign the performance review process for my team. I was resolved to rebuild their self-esteem and treat them with dignity. This new position would require me to meet with a group of software engineers regularly, but instead of abandoning them, I chose to use my newfound power to improve their working conditions.

What exactly is a software engineering performance review?

A performance review is a formal appraisal of a developer's work during a certain timeframe in software engineering. This evaluation considers a variety of aspects, including code commits, pull requests, code clarity, and problem resolution. It also considers soft skills such as communication and teamwork to determine whether the developers are reaching their objectives.

Why do software engineering performance reviews stink?

Performance appraisals are awful in general. And many companies, including Amazon, eBay, Adobe, and GE, are beginning to believe that it is past time to review performance reviews.

Performance reviews in software development must also be rethought. In my opinion, we should:

• shift our perception of performance evaluations

• move to a phrase that represents the contemporary problems in software development.

Here's my issue with performance appraisals:

Performance reviews can be a confusing mix of various elements

Are they intended to provide advice on coding efficiency, identify areas of strength and weakness, or revisit roles and expectations? It can be difficult to determine their purpose.

However, trying to address every aspect of a developer's performance in one review can lead to a lack of depth and meaningful feedback. In such cases, the review may end up achieving very little.

In the past, I've found this approach to be indicative of a supervisor's lack of preparation and attention to detail. It left me feeling uncertain about where to focus my efforts for improvement.

Focusing solely on metrics can make supervisors feel lonely

Because developers tend to leave companies when their managers prioritize metrics over considering their overall output, well-being, feedback, and growth.

While management experts often praise data-driven performance reviews, in reality, relying solely on numbers, especially in software engineering, can lead to problems. The bigger picture is missed when evaluating developers based on the number of pull requests or code commits they have made in a given time frame, as some projects may be more complex than others.

It is important to recognize that building software requires nuanced and unmeasurable thinking. It is a multidimensional endeavor that necessitates teamwork, creativity, problem-solving, and collaboration across teams. Quantifying all actions and work behaviors involved in software development is nearly impossible.

Moreover, tracking work patterns can be complicated, and errors may occur. Goals and contexts may also shift, producing data that may unfairly portray a developer as unproductive or lazy. Ultimately, relying solely on metrics for performance reviews erodes trust and morale and increases turnover rates.

Performance evaluations are critical in setting pay

If measurements are the entire emphasis of a performance evaluation and the only criteria utilized to set pay, the consequence might be terrible.

Unfortunately, many businesses continue to prioritize data as the most important factor in their reviews, even using it to determine promotions. In my experience, when developers are unsatisfied with their pay, whatever criticism they receive becomes meaningless.