The words sent chills down my spine. And when I sat and listened to my boss ramble on about aligning my performance with company objectives, I couldn’t help but think what a boring and unproductive ritual this was. There was hardly any mention of my biggest wins, much less my hard work, effort, and wellbeing. I left his office hating performance reviews and considering my departure from the company.
But then something happened that was unexpected - I got promoted to engineering manager.
Ironically, this new position required me to regularly meet up with a dozen or so software engineers. Instead of abandoning my direct reports and flipping the bird to the company logo on the way out, I decided to accept my promotion, but on the condition that I would be able to carry out a coup on performance reviews. I wanted to take back my engineers’ dignity and pay them the respect they deserved.
What Is a Performance Review in Software Engineering?
Performance reviews in software engineering are formal assessments of a developers' work in a given period of time. In software engineering, performance reviews look at code commits, pull requests, code readability, bugs, etc. They also discuss things like communication, teamwork, and to see if developers are meeting targets.
Why Performance Reviews in Software Engineering Suck
Performance reviews suck across the board. Fifty-eight percent of employees would agree. And many companies like Amazon, eBay, Adobe, and GE are starting to think it’s high time to review performance reviews.
Performance reviews in software development need a serious rethink, too. In my opinion, we should 1) change our mindset on how we perceive performance reviews and 2) transition to a term that reflects the current challenges we face in software development (hint: development conversations).
Here’s my beef with performance reviews:
Reviews Are a Mixed Bag of Everything
Are they meant to offer tips on how to code more efficiently? Maybe take the opportunity to discuss weaknesses and strengths? How about going over roles and expectations once more for extra measure? What the hell is it, then?!
Because reviews are often everything, it’s fair to say they achieve nothing. Touching up on every aspect of a developer's performance, but remaining on the surface, is as good as not having a review at all. In the past, this strategy signaled a lack of preparation and attention on the part of my supervisor. I left the review feeling lost about what I needed to take action on the most.
Metrics Alone Make Supervisors Lonely…
...because developers tend to leave their companies when managers focus too much on the holy grail of metrics. That, instead of holistically looking at developers from the point of view of output, wellbeing, feedback, and growth.
Management gurus often talk about data-driven performance reviews. But in reality, diving into the numbers, especially in software engineering, may get ugly. That’s because productivity in the IT world cannot be attributed to metrics alone. You miss out on the bigger picture. It’s not about how many pull requests or code commits a developer has completed within a sprint because some projects might be easier in scope than others.
Let’s be clear on one thing: building software requires unmeasurable nuanced thinking. It’s a multidimensional endeavor that requires cross-team collaborations in design, creativity, brainstorming, and problem-solving. It would be almost impossible to quantify all actions and work behaviors that go into building software.
Also, sometimes there are reporting errors and difficulties in tracking work patterns. Goals and contexts shift, and that too may produce problematic data, which then makes the developer look unproductive or even lazy. In conclusion, a numbers-only appraisal process breaks down trust and morale and results in a higher turnover.
Reviews Determine Salaries
Imagine metrics as the only talking point for a performance review. Now imagine an annual review alone used to determine salaries. A recipe for disaster, huh? Unfortunately, many companies still make data the be-all and end-all of a review. And these reviews are often used to determine whether a developer gets a promotion or not. In my experience, when developers don’t get the compensation they want, any form of feedback that comes after becomes pointless. Probably one of the biggest changes I’ve made as an engineering manager was to decouple performance reviews from salary negotiations.
Why We Should Call Them Development Conversations
Instead of looking back once a year and hammering your developers on what was or wasn’t done, how about looking forward monthly, or every two weeks, and coaching them on their deliverables? How about we start calling this a development conversation?
More Frequent and Feelingly
The performance review, which has traditionally been an annual occurrence pegged to pay raises, suffers a recency bias. Many supervisors, unless they’re very well-prepared, discuss things that have happened in recent weeks or months. This means that projects or tasks at the beginning of the year are often omitted from the evaluation. This black hole in the calendar, if not addressed, results in a breakdown of morale and trust. It also screams communication issues and a lack of honesty.
By having reviews monthly or every two weeks, it becomes easier to check up on your developers, to see if they’re crushing their goals, or if they’re confronting burnout. It becomes a genuinely mindful event that the developer will start to appreciate again. It will also make it easier for the developer to process feedback, discuss what projects succeeded or not and why, and talk about future goals. It even unburdens the developer from having to tell their supervisor what they want to hear just to get that pay raise.
Conversations, Not Confrontations
Something I’ve learned during my transition to engineering manager is to start the review by asking how my developer thinks he or she is doing on a particular task or project. This line of questioning levels the playing field and also allows the developer to set the tone and flow of the conversation.
After they share their feelings about how they’ve been doing, that’s when I give feedback. I don’t confront them, and I don’t use language that judges my developer. I mostly use data and feedback from teammates. Giving feedback, no matter how difficult it could be, should never be a test of patience and mental endurance. The developer should never leave feeling that it was a personal attack, but a call to action to become a better developer.
Two-way conversations - as opposed to the traditional one-way, boss-dominated grilling - also make the review feel productive and useful. They reduce the stress and anxiety of being called out on poor performance. Having a conversation also encourages your developers to come to sessions ready to engage you and discuss past projects and tasks.
Feedforward, Not Feedback
At the end of the feedback session, you as the supervisor need to have a clear picture of the developer's goals and where he or she wants to go in their career. If not, work together to hammer out a game plan that will get them there. And every time they reach a milestone, you do too, and you’ll feel super fulfilled.
When you notice your developer is partial to coaching, you can raise the bar again and encourage them to keep going. As long as their development persists, it shows that you’re also doing a job that aligns with your company’s objectives. When the above parts are accomplished, the developer walks away having complete trust in you as a great inspiration and resource in guiding them.
At the end of the day, we could all agree that giving and receiving feedback is hard, but it’s a crucial part of any development conversation. When you get into the rhythm, establish trust, and remove any bias or judgment from it, your meetings will go from being the most dreaded part of your company culture to something to look forward to. It becomes a win-win for everybody! This could, after all, be achieved if you start looking at reviews as development conversations.
