The ideas described here were developed in my role as a Director of Engineering for a large organization. The official performance review template was around twenty pages long and was generic enough that it could be used in any department. When my manager announced to his staff that it was performance review time, everyone (else) let out a collective groan and started clearing their schedules.
A few things became clear to me in that moment:
- No one liked performance reviews.
- Everyone at the company considered performance reviews a waste of time.
- The ‘Copy’ and ‘Paste’ features of Word were about to get a lot of use.
Performance reviews can add real value to an organization, but at twenty pages, the current system was probably a good idea with a bad implementation. With that in mind, I set forth to see if I could improve the process. My goal was simple: increase the value of our performance reviews — for both employees and managers — while reducing the amount of time it took to write a review.
The result was a performance review methodology that reduced the form down to a single sheet of paper. But the new process was more than just a review: it also provided a clear and unambiguous way for managers to communicate performance expectations to their employees.
Why have performance reviews?
The aforementioned meeting made it clear that something was wrong with the current review process. Rather than pick apart the existing review form, I decided to focus on the intent behind the form itself.
I studied the current form, discussed performance review concepts with other managers and, of course, did some Google searching. I ultimately determined that an effective performance review methodology would satisfy the following two objectives:
- Communicate job-related (not necessarily employee-related) goals for the position that is being reviewed.
- Rate the employee’s performance as it pertains to those goals.
Why the distinction between job-related goals and employee-related goals? Because I believe that you should immediately address per-employee issues — positive or negative — and not wait for a performance review to come along.
There are cases where you will want to use employee-related goals (discussed later in this document), but these are usually long-term items. Today’s issues should be handled today, not during the next performance review.
On a related note, you should not try to manage your employees through the performance review process. Reviews are like an annual physical with the doctor: neither party should be surprised by the results.
Problems with the current process
Both of the goals I identified are so simple, it is hard to believe that the current form did not address them. And in fairness to that form, it did address them.
But it also included a number of unnecessary items that confused the real intent of the performance review. The employees were rated on the organization’s values, for example. This is a bad idea. You either share a set of values with other people or you don’t. Besides, how can you rate someone’s ethics (one of the company’s values) on a scale of one to five? Does Employee A have ‘Outstanding’ ethics or do their ethics merely ‘Exceed Expectations’?
Put another way, the majority of the form was far from objective. Two managers, reviewing the same employee, would come up with entirely different ratings. Performance reviews become a permanent part of the employee’s HR file. As a result, I felt it tremendously important that they stand alone as an objective statement of the employee’s behavior.
Finally, performance reviews were done on an annual basis, requiring managers to identify goals that could be tracked over the full twelve months of the review cycle. A year is a long time for an engineering manager; we usually released two major versions of our product each year. The contents of the second release were usually decided late in the year, making it difficult to establish twelve-month goals that were relevant to each engineer’s job.
Creating a Better Review
The introduction to this article is something of a tease: it suggests that buried in this article is a single-page performance review form. And while that is true, the form in this article is probably not the right one for your organization. The right performance review form is one that is tailored to your specific needs.
This section of the article is designed to explain how to identify those needs and turn them into your own performance review methodology.
As you evolve your review process, there are a couple of items that should be kept in mind:
- The written goals on the performance review form should be as objective as possible. You will know you have succeeded if your employees are able to review themselves and choose identical ratings to those you would have chosen. Objectivity in the face of extreme bias should be your target.
- Those same goals should include elements from the employee’s job description. This does not mean that you have to begin with a formal job description, or even have such a thing. It simply means that the employee should not be surprised by the contents of the form.
- On a similar note, your employees should know what you expect of them at the beginning of the review period. The contents of the form should remain static during that same period, otherwise the validity of the form is compromised.
With those elements in mind, let’s discuss the tasks that go into creating a review methodology.
Identify review groups
Before you can start writing your review form, you need to figure out how many forms you are going to create. This is usually determined by looking at the different job descriptions in your department and creating a form for each unique position.
If you manage an engineering team and quality assurance team, then you will need (at minimum) two forms. If you manage multiple, disparate engineering teams, you may want to create a form for each team. Hardware engineers might have one form, software engineers another.
The same concepts can be applied to other parts of the organization. Product management teams for established products might have a different form than teams that are working on new products.
Your goal is to customize the forms to the specific needs of the position. Make sure that the objectives you define in the next section make sense for every member of the team. If they do not, you may need an additional form.
Define review areas
The review form for each group is divided into a set of job-specific performance areas. These areas should have high-level descriptions such as communication, teamwork, quality, and customer satisfaction.
Inspiration for these areas can come from a number of different sources:
- Use components of the position’s job description. Engineers are often rated on things like quality and timeliness. Communication is an important skill for everyone, as is teamwork.
- Is your department putting a new initiative into place? Perhaps there is a group-wide problem that you are trying to solve? Consider creating a performance area for the items that will support these tasks. This makes it clear to your employees that the initiative is one that you take seriously and is not merely a goal du jour.
- Ask your employees if there is something about their department that they feel needs additional monitoring. If the architectural integrity of the product is beginning to weaken, consider making that a section on the review.
Document rating levels
Each performance area should be rated on a fixed scale. My recommendation is to use the common three-tier review scale:
- Does Not Meet Expectations
- Meets Expectations
- Exceeds Expectations
Resist the temptation to create more than three levels. Additional levels make it difficult to objectively rate an employee. They also increase the complexity of the form and can lead to ambiguity during the rating process.
The review form must contain a clear description of the performance that is expected at each level; including the ‘Does Not Meet Expectations’ level. Describing both the positive and negative behaviors will help the readers of the form build a balanced view of what the organization expects from each employee.
These descriptions should be fact-based and as objective as possible. Avoid fluffy language such as “Makes use of standard engineering practices.” Try to include specific actions that your employees can take to achieve a given level of performance.
Everyone in the department should be able to interpret these descriptions in the same way and, given the same set of facts, be able to assign identical ratings to any other member of the department.
Determine review frequency
Annual performance reviews tend to cause the reviewer to focus on general issues, usually of a subjective nature. This is caused by the delay between defining an objective and reviewing it the next year. The employee will undoubtedly focus on the objective for the first few weeks, but it will surely get lost as new items come along.
This can be avoided by ensuring that the objectives are well-written, but it can also be avoided by increasing the frequency of the reviews. My recommendation is to tie the review process to one of the organization’s project schedules. Engineering, QA, and product management teams can be reviewed at the end of each product milestone or release.
Your goal should be to review your employees every three or four months. More often than that and you will spend all of your time conducting performance reviews. Less often than that and you might fall into the over-generalization trap common to annual performance reviews.
Frequent reviews provide a number of other benefits as well:
- The team’s objectives stay fresh in everyone’s mind.
- For those employees that need one, frequent reviews can create an official path for communication with their manager.
- Authors of the review form can create period-specific goals. Engineering managers can use this as an opportunity to define group-wide goals for each release. These can be invaluable for keeping your teams aligned as you evolve your product.
Keep the form up to date
You should reevaluate your form at the beginning of each review cycle. Do the contents make sense for the upcoming review period? Do any of the rating levels need to be changed? Are all of the review areas still relevant?
The core performance areas for each position will probably remain unchanged, but the definition of each rating level may need to be adjusted. Performance areas that were created as part of a group-wide initiative may no longer be relevant and should be removed from the form.
Implementing the Review
Once the form is done, the review methodology described in this article becomes fairly routine. You will be reviewing your employees more often than you might have before, but the process itself is much simpler.
Schedule the first review
Meet with your employees at the start of the first review period. If your review periods are based on product releases, then the meeting should be scheduled before the project begins.
Go over the form with your employees and discuss each performance area and rating level. It is especially important to explain why each of the review areas was chosen. If the discussion prompts you to make changes to the form, be sure to complete those changes before the review period starts.
Set a date for the reviews themselves and communicate that date to your employees. Depending on how you are structuring your review period, the date may be relative to your project schedule. My reviews were a task on our master schedule that depended on the final release itself.
Last but not least, make sure that everyone has a blank copy of the review form. Many of my employees posted this on their cube wall as a reminder of the performance areas for the current release.
Fill out the form
When filling out the review forms, take the time to read the descriptions for each rating level before deciding on a rating. Try to recall specific examples for each employee. These examples will guide you towards a rating and will also be helpful when discussing the review later on.
I usually complete all of my employees’ forms in a single session. When I am done, I compare all of the ratings to ensure that I am being objective in my assessment of each employee.
Meet with each employee
People tend to dread performance reviews, even when the review form is a single sheet of paper. The goal of this review methodology is what I call the “no surprises approach”. Your employees have had the form from the beginning of the review period and, if the form is objective enough, should not be surprised at their ratings.
Even so, you should schedule enough time to discuss the review with each employee, listen to their feedback, and give them an opportunity to comment on the review period from their perspective. I usually assign a block of time on my calendar for each employee rather than calling them into my office one at a time. The scheduled approach lets everyone know when their review is going to be. Again, no surprises.
Discuss the review
You can go over the ratings any way that you like. I usually go top-to-bottom on the form, citing the examples that led me to settle on each rating. I also have two copies of the form: one for me and one for the employee.
Although this article strives to help you build an objective review template, there may be cases where an employee contests a rating. If that happens, listen to their explanation and then set aside your ego and reevaluate the rating. There is the rare occasion when you will change the rating. Be certain that you are truly dealing with new information and not an especially persuasive employee.
After you have discussed the review, have the employee sign both copies, one of which you will give to human resources. The employee can keep the other copy for their records.
Discuss any changes to the review form
The majority of your review form will remain constant from review period to review period. If you do decide to make changes to the form — to add or remove a performance area, for example — make sure that you discuss the changes with your employees.
You can do this in a group setting as discussed earlier or one-on-one. Regardless of which method you choose, make sure that everyone gets a copy of the new form.
It is worth mentioning a few of the legal issues surrounding performance reviews. Before I begin, I need to state that I am not a lawyer and that most of my experience as a manager has been with companies located in California. Please discuss your performance review methodology with your company’s human resources department before putting it into practice.
With that out of the way, be advised that you cannot force an employee to agree to the contents of a performance review. You can only require that they have read the review and discussed it with their manager. This means that the employee should have an opportunity to voice their complaints with the review, documenting them if they feel it is necessary to do so.
Finally, I have found that most legal issues can be avoided by keeping the review as objective as possible.
Sample One-Page Form
The sections below describe each element of my one-page performance review form. The complete form can be downloaded as a PDF file. This document is a simple PDF file; the real form was made into a fill-out form using Acrobat Professional. Using fill-out forms made it much easier to write the reviews and allowed me to keep an electronic copy of the completed forms.
Some background on this form:
- A recent re-org had integrated my stand-alone engineering organization into part of the larger, 300-person engineering team. As a result, I placed an emphasis on communication to ensure that my employees were working effectively with the other teams.
- Our product had taken a very evolutionary growth path and parts of the architecture had suffered as a result. I wanted us to get back on track with good design principles.
- We were in the process of rebuilding the quality assurance team and I wanted to make sure that my engineers were taking the time to work with the new team.
Note that I had already discussed these items with my staff. The performance review was used as a reminder of these items, not as the sole method of communicating them to my employees.
The review areas were organized from the most objective areas to the least objective areas. This was purely a matter of aesthetics; you should order your review in whatever way makes sense to you.
The quality of an engineer’s deliverables are just as important as the deliverables themselves. My organization was also in the process of restructuring its quality assurance (QA) department, so choosing quality as an item on the review made a great deal of sense.
The goal was to take the basic elements of quality as they pertain to a software or hardware engineer and combine them with our departmental objectives. The result was a clear description of each review level.
|Exceeds Expectations: Fixes bugs quickly. Works with QA to help create test plans. Aggressively monitors the bug tracking system to look for — and deal with — their bugs.||E/M/D|
|Meets Expectations: Fixes bugs in a reasonable amount of time. Proactively tests code. Does not wait for QA to find known issues or to test edge cases.|
|Does Not Meet Expectations: Has an excessive number of bugs and/or takes an excessive amount of time to fix bugs. Does not adequately test changes before checking them in. Requires multiple changes to fix a single bug.|
This section of the review form is a good example of how an area can evolve over time. The focus of this review’s Quality section was to get the engineers to make a greater effort to instrument their code and contribute to the testing process. These actions needed to become automatic and putting them on the review form helped us get there.
When the next review cycle came along, some of the items from the “Exceed Expectations” level moved down into the “Meets Expectations” level. I felt that we would most easily achieve our department objectives if we took intermediate steps towards those goals. In this case, we focused on the issues that we could fix in engineering before turning our attention to the other teams that we worked with.
Timeliness is a very straightforward area in which to review an employee: deliverables are either on time or they are late. There is an additional spin here however, which is that an employee that “Exceeds Expectations” should not only get their projects done on time, but should assist others to do the same.
|Exceeds Expectations: Consistently ahead of schedule in completing deliverables. Works to help others get their projects done on time.||E/M/D|
|Meets Expectations: Completes deliverables on time.|
|Does Not Meet Expectations: Deliverables are consistently late.|
One of my managers gave his employee an ‘M’ in Timeliness, but an ‘E’ in almost everything else (this employee was definitely exceeding our expectations, hence the stellar review). The surprising comment from the employee was that, “[he] was glad he didn’t get an ‘E’ in Timeliness, because that would have meant he was padding his estimates.”
There is some merit to this comment. Your employees should be encouraged to come up with accurate estimates and not be penalized for being (a little) wrong. Estimation is a complex skill that is best learned through experience. Depending on the seniority of your employees, you may want to adjust this section to focus more on scheduling.
This example also underscores the need for the additional component of the “Exceeds Expectations” level: an exceptional employee will help others with their planning.
A big part of our departmental goals for the year was improving our software architecture. Our product was feature-rich, but some of those features came at the expense of good design practices. As a result, architecture featured heavily in the performance review template.
|Exceeds Expectations: Aggressively looks for ways to improve the product. Presents refactoring plans. Refactors code as they are adding new code. Presents innovative solutions to problems.||E/M/D|
|Meets Expectations: Cleans up code as they are adding new code. Calls attention to questionable examples in the code. Makes an effort to correct those issues.|
|Does Not Meet Expectations: Does not make an effort to improve the code base. Consistently writes poor code (lack of comments and documentation, poor coding practices, etc.).|
Many of these items are somewhat ‘soft’ compared to the more objective descriptions in the previous sections. It is very hard to quantify good architecture. Most attempts at turning engineering into a set of numbers and statistics result in a rift between management and engineering.
My goal was to be as clear as possible with these examples, knowing that a certain amount of subjectivity was unavoidable. I had a great engineering team and knew that I would be able to communicate the intent of this section to them. The review form is only part of the system; you must ultimately rely on your managers to implement the process. This requires that both your managers and your employees understand the goals of each performance area.
Two recent changes in my department encouraged me to place a strong emphasis on communication: we had recently deployed a WikiWikiWeb site and had also merged with an engineering department in a different part of the state.
The engineering team took to the Wiki pretty well. Some of the engineers were reluctant to edit “other people’s” pages, so I made it clear on the performance review form that editing was encouraged. This helped a great deal towards improving the value of our Wiki.
|Exceeds Expectations: Routinely adds pages to the Wiki, cleans up existing pages, identifies pages that need to be created. Actively participates in meetings. Aggressive about sharing information.||E/M/D|
|Meets Expectations: Creates a Wiki page every now and then. Modifies pages directly related to their work. Attends meetings.|
|Does Not Meet Expectations: Does not create Wiki pages or modify existing pages. Does not contribute to meetings. Not proactive about sharing information.|
Many of my engineers made an effort to achieve the “Exceeds Expectations” level in this section. Their efforts helped us to better integrate our team with the rest of the distributed engineering team. The performance review form was a constant reminder of the high-level goals that our department had throughout this time.
The last section in my review is by far the least objective, but I also consider it to be one of the more important sections of the template. As I mentioned earlier, my department had recently merged with one of the larger, off-site engineering groups. It was critical that we view these new engineers as first-class members of our team.
|Exceeds Expectations: Makes a significant effort to assist other team members with their projects. Helps bring together individual engineers and engineering teams to improve the product.||E/M/D|
|Meets Expectations: Works with other members of the team to complete the release. Considers the impact that their actions have on other team members.|
|Does Not Meet Expectations: Blocks the efforts of the other team members through poor quality, poor design, etc. Has a negative attitude.|
You can see how subjective these descriptions are. The key to fairly rating employees with a section like this is to have clear examples for each employee that can be tied to the text on the review form.
The form includes a blank space where the manager can add their own comments to the review. Although there are many uses for this section, the most common is to include justifications for the ratings themselves. This is especially helpful in the case of the ‘Exceeds Expectations’ and ‘Does Not Meet Expectations’ ratings. Managers should be encouraged to keep this section as objective as possible.
The Two-Page Form
The one-page form has been very successful with groups of all sizes. That said, some of the directors at my company were concerned that the form did not provide a section for employee-specific objectives. I was torn over whether or not this should be part of the review methodology.
On one hand, employee-specific objectives allow you to personalize the review form and work with individual employees on medium- to long-term goals. On the other hand, not all of your managers may be able to write these goals in an objective manner.
I ultimately decided that the form should offer a place for including employee-specific goals. This would be a good chance for me to work with my managers on defining clear, objective goals for their team. I asked the managers to include additional goals only if they felt it was necessary. Some used all four spaces on the form, others used only one.
If you decide to include this second page in your review methodology, you should have your peers and/or next-level manager look over the objectives with you before you give the review to the employee. Creating a review methodology is almost always a team effort; creating employee-specific goals should be no different.
You can download the two-page form as a PDF file. It is virtually identical to the one-page form, with the exception of the “New Objective” boxes on the second page and the “Results vs. Previous Objectives” section on the first page.
It is imperative that your customized goals include the descriptions of the performance expected at each rating level. Employee-specific goals should look the same as the job-specific goals.
More Sample Forms
The same methodology was used throughout my department. Some of the other forms are included here for your review.
Quality Assurance Engineer
I managed the quality assurance team in addition to the software and hardware engineering teams. The QA form contains many of the same departmental objectives as the engineering form, but replaces the engineering-specific sections with those that are more relevant to the quality assurance group.
There are a number of extensions to this review methodology that I would like to implement. Each of these is discussed below.
The most obvious improvement to the review process is to build a web-based system of managing reviews. The forms could easily be stored in a database, as could employee-specific objectives. Electronic sign-offs could be used to move the forms through the review process. A complete archive of each employee’s reviews would be available to the management team, human resources, etc.
I built a prototype of this system a few years ago and was pleased with the early results. If there is enough interest, I would certainly consider turning it into a real application. Please contact me if you think that this software would be useful to you.
In its current form, a performance review is a one-way contract between the employee and the employer. The employee agrees to perform at a certain level and has to take it on faith that their manager will do the same.
I believe that great value could be added to the review process if it was made bidirectional. Managers should agree to a set of goals and ask their employees to review them on those goals. This can be done using the same style of performance review that is discussed throughout the rest of this document.
It is important to state that the majority of the goals should be identified by you: the manager of your department. Employees who do not have management experience may focus on local issues at the expense of department-wide objectives.
A variety of issues need to be addressed when implementing reverse reviews:
- Should the reverse reviews be official (go in your HR file) or are they an informal document used to facilitate communication with your employees?
- Is the reverse review designed solely for your use, or will your manager see the contents of the form as well?
- Should your employees get together and fill out a single review, or should each employee complete the review individually?
- Which review form should you use: the one-page form or the two-page form? In other words, should you create goals for yourself after talking with your employees, or do you want your employees to suggest goals on the review form?
I have not yet had a chance to implement reverse reviews, so I cannot provide answers to those questions based on experience. I do have an idea of how I would start out, however. If you are interested in trying out reverse reviews, please contact me with any questions, suggestions, etc. that you might have. I would be happy to assist you with the process of designing and deploying the form.
My experience using this review methodology has been a very positive one. Many of the employees and managers that I have worked with have said how much they appreciate the clear, objective goals that come along with the process.
In the end, I spent more time designing this system than I would have spent filling out the twenty-page review forms. But the results were definitely worth the effort.