The Performance Review

Ahhh, the performance review. So hated and so feared. Or so loved, if it goes well.

Years ago, I used to be extremely anxious about this moment and tried to compensate for the stress by drowning myself in data collection. I spent nights on GitLab downloading commit and push data, checking sample cards on Jira, reviewing threads on Google Chat (the tool we used back then)... a complete mess.

In the end, I was lucky. I had a very strong team. So it wasn't difficult because I had to give bad feedback. It was difficult because I was afraid of giving too little to someone who deserved more and too much to someone who deserved less.

But the real problem was something else. I suffered from what's called 'absolute fairness'. That is, the idea that there must be an exact point where everyone gets exactly what they deserve. Unfortunately, absolute fairness doesn't exist. So if you act like I did, it's time to stop torturing yourself: you'll never reach that perfect point, and for your own (mental and physical) health, you need to take a different approach.

My struggle was also due to time constraints. In those years, I was both a manager and a programmer. And that's the best way to end up with a clogged mind, because you switch from technical problems that require focus down to the grain of sand, to high-level problems that need a bird's-eye view, often within just a few minutes. Devastating.

At some point, when I transitioned back into an Engineering Manager role, I decided I wouldn't be a programmer anymore. I had already adopted this phrase during my final years as a Team Leader (before going back to being a programmer for about five years):

Either you're a manager or you're a programmer. Otherwise, when people are looking for the manager, you won't be available because you're busy committing/pushing. And when they're looking for the developer, you'll be dealing with a critical situation (like the performance review).

That's the rougher and probably more rigid version of what Johanna Rothman says:

We strongly recommend managers avoid technical work that's on the critical path - it's a no-win situation. When the manager attends to management work, their technical work suffers; when attending to technical work, the team proceeds without a manager.
- Rothman, J. - Derby, E. (2005). "Behind Closed Doors", p. 99

In her book, Rothman is more open to the possibility of managers working on less critical technical tasks.

Now that it's clear how difficult it is to set up a performance appraisal when you're also programming, here's how I handle it. First of all, to me, a manager must think long-term. Some managers I've known don't do this at all. Many hide behind the phrase 'we're always caught up in urgent and (apparently) important issues'. I don't really believe that excuse anymore. Sure, in some places it's probably true. But from what I've seen, many managers don't even know what it means to 'try to look a bit further ahead'.
I don't know either, to be honest. I don't want you to think I have 'the answers'. But I'm studying. 
And performance review is definitely a long-term thing (if one year counts as 'long').
So as we were saying, if you make the effort to consider long-term topics instead of being dragged around by last-minute fires, it becomes essential to think about the performance appraisal in January, not in November or December when everything is already decided.

Paul Falcone once said:

There are three components of the Performance Management Cycle:
1. Goal setting and planning
2. Ongoing feedback and coaching
3. Appraisal and reward 
The annual performance appraisal clearly speaks to the third issue, but appraisal and reward can't be accomplished in a vacuum

When thinking about how to handle performance reviews, I often go back to what becoming a leader meant for me. I have to admit I feel a bit awkward talking about these topics, because I remember becoming a Tech Leader for the first time at 31. But the company was full of blame, always looking for scapegoats, so I resigned. After a few companies and roles, I went back to being a tech leader at 35 and never left that path again, except between 2020 and 2025 when I returned to being a full-time developer.

What's interesting is that I've always felt like a leader inside. I remember, for example, standing up to a so-called leader back in 1999, when I was 24. In a Java project (I think we were using JDK 1.1.8), the tech leader wanted us to use 'for' loops starting from 1. It was because he came from Visual Basic, where that was the norm, and he wouldn't accept that other languages might do things differently.
I called that out as nonsense, and the other developers looked at me like 'finally someone who gets it and says it out loud'. Later I learned that there are ways and ways to say things, but I don't want to remove that rebellious spark from this post - it's part of what makes coding fun.

In any case, in every company I've worked for, I always had the technical skills to stand out. Driven by a passion that kept me coding at night, hungry to learn. But technical knowledge alone isn't enough to be a good leader, and I think that's why my growth was a bit slow.

So I often ask myself: "how do you become a leader?"

The book "The Leader in You" by Dale Carnegie wasn't very helpful, to be honest. 
At least it was one of the first to state clearly that "Leaders are made, not born".

The real issue I see is that many people truly believe that leaders are born. You've surely heard things like "he's a natural leader" or "you have to be born that way".  

But no. Leaders are made.  

(By the way, one of the most ironic things I witness is people explaining the growth mindset, and then turning around and saying things like 'you're either born with that skill or not'. Makes you wonder if they really got what growth mindset means.)

Back to us. If leaders are made, then we need to invest time in creating them. A lot of time, in fact. What's also interesting is the way we create leaders.
I like the distinction that David Marquet makes in his book "Turn The Ship Around". He explains that his leadership model is called leader-leader and aims to create leaders at every level. The usual model he calls leader-follower, where the leader is you and everyone else is a "follower". He also makes a very important point: as a leader, you can't use leader-follower rules to force people to adopt a leader-leader mindset. That shift has to happen willingly:

In reversing years of the leader-follower system's erosion of the chiefs' authority, the chiefs on board Santa Fe - now under my command - would be going against the grain. I wanted to make sure they deliberately decided to take charge. It wouldn't be any good if I directed them. You can't invoke leader-follower rules to direct a shift from leader-follower to leader-leader.
  - Marquet, D. (2012). "Turn The Ship Around", L. 950

That's why it takes time.

Honestly, there are a few things I've learned from experience that help spot potential leaders. One is this:  "If someone complains, rejoice. It might mean they're the only one who still cares about what you're doing."
Basically, the one who complains might be someone with leadership potential, but they keep getting blocked - sometimes in very silly ways - and so they start pushing back. Watch out. Among them are "baby crocodile leaders": yes, they bite here and there, but they're manageable and could have a great future.

To explain this idea - which might seem trivial - I'll mention something I read in "Trattato di Sociologia" by Franco Ferrarotti. He explains a thought by sociologist Adam Ferguson, who believed that conflict has always been at the core of human and civil evolution. The reason is that man is a free and active being. And he added that many people would like humans to be motionless like a brick wall, but if you think about it, that's the perfect image of slavery.

I see a connection here with those leaders who others would like to see passive, compliant. But instead, they push back. Why? Because they're leaders. (Of course, sometimes they're just jerks. It happens.)

But aside from these little tricks to identify leaders, how do you actually become one?  

For years I've used a list of skills (it was much shorter in the beginning) and I try to define parameters for each level of the ladder for every skill. Then I evaluate each person against them.

Here is my skill list:

• Adaptability and Change Management Skills
• Attendance and Punctuality (Reliability)
• Communication and Cooperation
• Creativity and Innovation
• Diversity Orientation
• Goal and Objective Setting
• Initiative
• Job Knowledge
• Judgment and Decision Making
• Leadership
• Listening Skills
• Managerial Style
• Oral and Written Expression
• Organization and Planning Skills
• Personal Style
• Problem-Solving Skills and Results Orientation
• Productivity and Volume
• Professionalism
• Quality
• Staff Development
• Strategic and Critical Thinking Skills
• Supervision
• Teamwork and Relationship-Building Skills
• Technical Skills
• Time Management

It takes time to evaluate, and many of these skills overlap. At the beginning, I would fall back into the "absolute fairness" mindset - now I try to let it go and move forward. Also, I don't expect everyone to excel in everything or to hit the exact number set by the ladder. Everyone has strengths. I write them down and keep focusing on them, because reminding someone how good they are at something they're naturally good at is a real confidence booster. And that's when you can start talking about how to improve the rest. At that point, you're dealing with a motivated person who feels appreciated.

So then I set goals for each skill that I think should be developed. They're not defined using the S.M.A.R.T. method. Honestly, I don't really believe every goal should follow that structure. Maybe I'm wrong to even call them goals, but let's say I describe what should roughly happen in order to say someone has reached a suitable level in that skill.

I keep track of what happens. I ask the person to help by pointing out moments that could show improvement. If I see signs to the contrary, I give immediate feedback. If I see growth, I mention it in the next one-on-one.

Lately, I've been experimenting with quarterly performance reviews, not just the semiannual and annual ones required by the company. I think it helps people stay oriented during the year. How frustrating must it be to work all year and then find out your manager was unhappy about a bunch of things? Sure, there's ongoing feedback, but I prefer knowing that the person has received a summary review every three months. I like that approach.

Another thing I'd like to try - which I haven't done yet - is to ask people to define their own goals in certain skills. That's an experiment for the future.

This is how I currently manage performance appraisals. 
It might change. I'm still learning. 
In the end, what matters is that it works - and to make it work, you just have to try. 
But let's not start trying in November or December. Let's start in January!