I have received ~15 annual reviews in my 21 year career. Most of them weren't useful, some were actively bad. I often joke that annual reviews are more a reflection of the organization and manager than they are the employee.
And with my manager hat on, I've also handed out my share of annual reviews. (And hopefully I didn't score too badly on those).
From my own experience, discussions with others, and broad reading, it's pretty clear that annual reviews are a net negative. However, that doesn't stop organizations from requiring us to go through the theater.
Traditional performance reviews and approaches to feedback are often so bad that they actually make performance worse about one-third of the time.
Here's how I provide real feedback and value for my teams and force the annual theater to work for us.
Why do we perform reviews?
Stepping back for a moment, why do we perform reviews?
The purpose of managers is to enable our team to execute effectively against business goals and metrics. Whether we're telling people what to do, or enabling them to autonomously use their expertise, our job is to ensure they know what's expected and are receiving feedback to know how they're doing against those expectations.
Performance reviews one way we enable individuals to do their best work on the team, and satisfy that broader responsibility to the team.
Evaluating Performance
When we talk about performance evaluation, the implicit part is that we're evaluating their performance against a set of expectations.
In the absence of clearly defined and agreed on expectations:
- people make up their own, based on past environments and other drivers
- leading to everyone on the team operating towards different goals
- leading to additional coordination costs and rework from misunderstandings
- and opportunity cost: missed opportunities for folks to not only operate to expectations, but grow in ways that compound and produce even greater results on an ongoing basis
To Execute and Improve
And we evaluate performance because we want improved outcomes for the business and team members. This means in the day-to-day operations, but also adapting and improving for great performance in the future.
In the absence of good feedback
- People make their own assumptions and sometimes read the wrong context into otherwise innocuous statements
- Misunderstood expectations are embedded in long term behavior and passed on to new teammates
- Improvements can't be made, only changes (did it get better, did it get worse, who knows?)
And Communication is Hard
We're human. It's an often repeated management aphorism that just about when we're getting tired of repeating something, folks are just starting to really hear and understand it.
So to get those "clearly defined expectations" into people's head, to get feedback heard, understood, and internalized, that's going to take a lot of repetition and reinforcement (and luckily the evaluation process really helps with the clearly defined expectations part).
And Everything Is Changing
Company growth, market changes, tech changes, hiring, firing, re-orgs...
We're not going to stand still. Some expectations will stay relatively similar over time once they're defined, such as the base expectations for someone in a Senior Engineer role (more later), some are going to be changing frequently as projects come and go, or the team performs continuous improvement and experiments to become more effective.
Once/Year feedback is not remotely close to enough
Relying only on an annual review process, no matter how much energy is put into it, is not sufficient. It's performative, even before people approach it as a "check the box" exercise.
Clearly defined expectations (this is what we expect, how we work together, how we grow) with regular feedback produces better results, faster growing individuals and teams, and higher morale.
An Alternative to Annual Reviews
There's some work involved, but luckily it's already part of our job description as managers. Really we're just playing catch up.
- Define expectations
- people's roles:
- what is expected from each role, at varying levels of seniority
- how do we evaluate execution and growth
- the team:
- what is expected from the team
- how do we evaluate performance or enable it to happen within the team
- people's roles:
- Communicate them, a lot
- Early review for buy-in and engagement
- Public communications
- New members and ongoing reinforcement
- Provide feedback against them
- Frequency and methodology for structured feedback
- And spot feedback along the way
- And probably still fulfill an annual review process
1. Define expectations for roles
Defining the expectations for a role is one of the first steps, and can be a lot of work. Luckily, this one step also pays off across a lot of different aspects of our job. From writing job ads, to designing and performing interviews, to writing improvement plans, all are easier and more consistent when we have take the time to create and write down the role expectations.
Explicitly defining these expectations also gives us space to really think through them, end to end, and ensure they're tied to the business and team needs.
The most important pre-cursor to any performance evaluation is mutual agreement on what is reasonably expected of that person.
I'd advise creating role descriptions for each type of role on your teams, it forces you to think about what is valuable to your company and consider what type of proof or experiences you would see from someone at earlier or later skill in that role:
- Creating Developer Career Ladders (tiernok.com)
- Product Manager Skills by Seniority Level — A Deep Breakdown (medium)
- Design Team Levels Framework (google docs)
- Introducing SREs, TPMs and other specialized roles. (lethain.org)
Our startup didn’t have formal titles. We just raised a Series-A round, and along with it we brought on new leadership. After some intense closed-door discussions they assigned everyone job levels and many engineers are angry to discovery they’re “Junior.” → Oh crap, titles don’t matter until they matter. Now lots of people are angry and upset
2. Communicate, a Lot
In this last framework rollout, I started communicating the goals and broad themes well in advance. I had a communications plan that included sharing drafts of the framework with leadership and members of the team, a review of the first version together as a team, individual 1-1's to perform a first round of evaluations against the framework, and an outline of the frequency we'd be re-visiting it.
That's a lot, but it all had purpose.
Communicate Goals and Themes in Advance
Before I was ready to start reviewing drafts with the team, I wanted them to be aware what I was working on and why. In this recent team, folks bought in very fast. They understood that it would provide them more clarity on how to grow in their current roles, a frequent topic in 1-1s, and that they would have more visibility into what those expectations instead of trying to interpret once/year gut-driven feedback as part of a larger whole.
So I had two goals: (1) provide a clear plan to address folks desires to growth and see results from that growth, (2) get folks thinking about what expectations they currently considered to be important and plant seeds that would be valuable in 1-1s up to the first draft being available.
Early Draft Reviews
The draft reviews by the team had three goals:
- Editing: Get additional eyes on the framework to make sure I hadn't missed major items, that the terms I was using made sense, and that the structure (groups) meshed well with our existing culture
- Communications: Really engage people's brains and skip a couple levels of repetition. "Come find the things that are wrong" receives a much higher level of reading engagement from folks than presenting them in a meeting
- Buy In: Including them in the process to challenge and refine the framework improved buy in
The draft review with other executives had two goals:
- Buy in, as above
- Pressure testing: was the method for defining expectations acceptable to the group, and did the categorization of skills make sense or generate any type of high-level gaps or concerns
Release Communications
The release communications were almost a non-event. I used the level of engagement from the prior activity to identify who was digging into the details more or less. For my team, I was lucky that everyone was really engaged, asking questions, and challenging gaps. They had each gone through their own roles and the one above, at a minimum, and put some real thought into the categories and described expectations.
This shaped the release. Given the level of review and engagement, when we released the framework we reviewed just the categories again, the terminology for how we would evaluate* growth or performance, and a couple samples, from Entry level through to the most senior level (Senior Staff in this case).
3. Provide feedback
Building on the Communication plan was the Evaluation plan, which defined the frequency we would evaluate folks on and what the outputs would be.
Structured and Regularly Scheduled Feedback
In the example case I've been using, the feedback plan was:
- We'll do one set of initial performance evaluations as the framework releases - this will help test the framework further and define a baseline of where each person is now
- We'll perform quarterly re-evaluations together
The output was:
- A shared document for each team member that outlined a common understanding on each of the skills based on what they qualified for now and possibly one level up if there were projects or other proof of growth against a higher level
- A review of areas they could focus on growth above and beyond their current role on in the next quarter, or areas to look for opportunities if the projects weren't well defined yet
- A shared agreement on individualized expectations for them. The framework is a generic "this is a Senior Developer for company X", but people develop differently. Having a baseline for their specific current skill levels and areas to grow in meant we could evaluate them each quarter from their own baseline as they grew.
And spot feedback
Within that structure, it was then easier to ensure operational, day-to-day feedback was happening.
In this case, there were several sources of feedback:
- Direct feedback from Teammates during design and code reviews
- Retrospectives that reinforced introspection and direct feedback from others
- External feedback from folks outside the team
And behind the scenes, I collected feedback from all of these sources, direct comments from folks during 1-1s or management meetings, and so on, so I could provide spot feedback regularly.
4. ...The Annual Review
Like us, you may still need to satisfy an annual review requirement. However, this should be a curation and summary exercise now.
We have shared notes and expectations to draw on, likely in more detail than anyone has had for annual reviews prior.
- Employee "self assessment": provide some guidance on how to summarize and collate the deltas and nots from the past year
- Manager write-ups: basically the same
There should be no surprises.
Promotion?
Another problem with annual reviews is that they often try to bundle a lot of topics into one discussion, for the sake of efficiency. It doesn't have to be that way.
While pay raises, performance improvement plans, and such are related, they need entirely separate posts (this one's way past long enough).
Promotion Discussions
The process above provides a lot of visibility into people's individual growth. The framework ought to have clear guidelines on how promotion occurs.
The biggest barriers tend to be:
- Budget cycles often dictate a limited frequency or time of year for promotions to happen
- Promotions are often looked at as something to be granted from on high, without differentiating between progression-based and new roles
In my prior role, I had agreement that progression-based promotions were determined based on the growth framework and that new roles would be handled by the older process. Part of the rollout of the framework was explaining how promotions would be handled, so there would be no surprises.
And Team Reviews
If we look back over that whole list, the same major elements also work for team reviews. If we have a team charter that defines the methods and goals of the team, project charters or goals for each of the projects we've taken on, and some form of higher-level business goals, then even a loose process of sitting down with the whole team every quarter (and maybe sending a questionnaire out to neighboring teams) can enable the team to have feedback at the team-level, potentially even fitting this in to a regular retrospective process as a specialized kind done at lower frequency.
Annual Reviews are not sufficient
Annual reviews are not sufficient, but feedback is an important responsibility of the job.
Defining expectations for roles can be a lot of work, and really is only one piece of our overall job in defining expectations, but winging it every turn costs at least as much, with opportunity costs added on on top.
There are a ton of resources out there, and hopefully some of the references I collected above will help you.
