Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Agile Performance Reviews

Agile Performance Reviews

What Are We Doing Wrong

By and large, the annual performance review process at most companies is broken. The very idea of having a meaningful conversation about performance once per year is laughable. Unfortunately, this mentality persists in many of today’s corporations. Most people simply don’t know a better way, and despite constant grumbling and cynicism from the staff about the process, few companies are willing to change.

Unfortunately, the prevailing advice right now is to simply eliminate performance reviews altogether. I suppose that if your choice was to either keep performance reviews as they are currently, or to eliminate performance reviews, elimination would be the lesser of the two evils. This article is an attempt to propose a third solution to the problem.

Certainly Adding Objectivity Couldn’t Be Bad

For the companies that do accept the need to change, they generally end up going the wrong direction. They hear complaints about the process being unfair in one way or another, and they attempt to pile on a bunch of objectivity in order to correct the perceived unfairness.

There are two main problems that make objectivity a pipe dream in performance reviews. The first is that any key performance indicators that are easy to measure are rarely the things that you really care about. For instance, should sales quotas be a part of the performance review for your sales team? What if one of your salesmen promised a customer that a product would have certain features that it currently does not have in order to close sales? They can make their quota by doing this, but they can cause a lot of trouble for the rest of the company. I doubt you would consider that good performance, despite them meeting their quota.

The second major problem with this approach is that, even conceding that you can find very specific things on which to measure performance, human judgement still has to enter the picture in order to make a rating for that key performance indicator. As soon as human judgement enters the picture, all objectivity is cast out the window.

I completely understand why it seems like we should strive for objectivity, but I feel strongly that objectivity is the wrong approach. In addition to the reasons mentioned above, consider that there are many different roles within your organization, and coming up with the same objective criteria for each of those roles is an impossible task. You would have to create different key performance indicators for each role, which would be an incredible amount of work for the organization. And, even then, the strengths that make one employee good at their job are completely different than the strengths that make another employee, in the same role, good at their job. Adding objectivity to your performance reviews is an uphill battle that you’ll lose every time.

Move Away From KPI and Towards Free-form Feedback

Instead of rating employees on row after row of key performance indicators, try providing them with meaningful feedback about behaviors that they exhibit. While results are what the company wants to see, targeting behaviors that lead to those results is the proper way to give feedback to an employee, positive or negative. This feedback should target behavior, should be specific enough for the employee to understand what was desirable or undesirable about that behavior, and should explain why you care about that behavior.

On a side note, for feedback to have the maximum impact, it needs to happen as close to the observed behavior as possible. What this means is that anything that appears on an employee’s review should have already been discussed with that employee at some point during the review period. If the employee is surprised by something on their performance review, you have some work to do as a manager.

Embrace Subjectivity

Since you’ll never be able to eradicate subjectivity from reviews, I propose that you embrace the subjectivity. Instead of trying to come up with specific criteria for each job, strive to provide the employees with positive and negative feedback based on the mission, vision, and core values of your company. Here are some examples of what that might look like.

Q: What does the employee do well?

  • When we needed a QCP solution for a customer, you stepped up and volunteered to learn new technologies to make it happen. Always add value.
  • When on an extended support call, you overheard the customer mention she was hungry and ordered a pizza for their office. Delight the customer.
  • When a customer installed software on their server that broke compatibility with our system, you got the team together to come up with a solution. Create and innovate.

Q: What could the employee start doing that they don’t already do?

  • I know you don’t like to sit through customer support calls, but sometimes that support reps really need developer input to solve problems. The whole company is my job.


Goals are another focal point of an effective performance review. Activities around goals usually fall into two categories, grading goals set during the previous performance review and setting new goals. Time and attention should be paid to goals, as these really help the employee and the manager focus on developing professionally.

These goals should not be given to an employee, but rather the manager and the employee should work together to create goals.

I’m sure we’ve all heard that goals need to be S.M.A.R.T. (Specific, Measurable, Attainable, Realistic, Timely). But do we need goals at all? Personally, I feel that if an employee clearly understands the expectations of the job, they can be successful. I’m not going to force anyone to come up with some arbitrary number of personal or professional growth goals above that. I would certainly prefer that someone stretch themselves and attempt to exceed those normal duties, but just meeting expectations is still a successful employee.

However, there’s a big difference between a successful employee and a “strong” or “outstanding” employee. If I choose to spend my time at home playing with my kids instead of attending training or reading books about leadership, I don’t think I should be penalized for that. I can still come into work and do a good job.

Feedback From Your Peers

One of the most powerful aspects of a performance review is feedback from peers. There are many ways to collect and deliver said feedback, but I usually anonymize feedback in order to encourage candor and honesty. However, this does not mean that anyone can say anything about another person and be off the hook. If you can’t back up your feedback with specific behavior, you’re not helping, you’re complaining. Complaining is not going to go on a review.

A plus for peer feedback is that it will greatly aid in the creation of the review itself. It can help to ensure that there is nothing that the manager missed when working on the rest of the review and it can help provide some more specific examples to include in other places on the review.

Soliciting peer feedback is pretty easy to do, and should be done three to four weeks ahead of delivering the final performance review. This gives people enough time to provide meaningful feedback to the manager, while also allowing the manager to follow up with people if there are any questions about particular feedback.

Recognize that not everyone is going to be comfortable providing feedback about their peers. Some people will only give you positive feedback, some people will provide very vague (and thus unhelpful) feedback, and some people will give you no feedback at all. Don’t push too hard, but feel free to train others in the organization about how to provide feedback, and ensure that you’ll keep the feedback anonymous in order to garner candor. It might take several review cycles to get everyone comfortable with providing feedback, but the results are definitely worth it.

We’re All Still Just A Number

Lastly, because at some point we HAVE to, but not because I like to, we have to rank employees against a known scale. I’ve played around with a lot of scales, and the one I like the most is essentially a five point scale that goes something like unsuccessful, variable, successful, strong, and outstanding. Right in the middle is “successful”, which is just what it sounds like. You come in everyday, you meet expectations, you get the job done. There’s absolutely nothing wrong with that, but there’s room to grow.

Unsuccessful employees simply aren’t getting the job done, and are usually causing a distraction in the workplace. It’s quite rare for an employee to receive an unsuccessful rating on an official review, because unsuccessful employees are generally removed from the organization long before a formal review is conducted.

Variable employees can be outstanding at some tasks and unsuccessful at others. Variable employees also tend to not be with the organization for very long, so seeing a variable rating on a review is typically pretty rare. Certainly the same employee should never get a variable rating twice in a row. A variable employee who is not improving is probably one that should be removed from the organization.

Strong employees tend to perform at very high levels most of the time. Not only are they performing their job very well, but they’re pushing themselves towards growth by reaching outside of their comfort zone.

Finally, outstanding employees excel at everything they do, and encourage others to do so at every opportunity. Outstanding employees are typically rare.


SAMPLE Performance Review

Review Timeframe: Q3 – Q4 2011

Employee: Sir Mix-A-Lot

Do Everything with Integrity and Honesty.

Delight the Customer.

Always Add Value.

Create and Innovate.

The Whole Company Is My Job.

Never, Ever Give Up.

Be Fearless, but Not Reckless.

Have Fun.


Things that you do well

As the product engineering team adopted Scrum, you jumped on board early and really pushed the adoption of the new process. Where a lot of people would be scared of change, you embraced it. Be Fearless, but Not Reckless. Always Add Value.

As we began adopting more of the engineering practices that come with great software development, you again jumped in and immediately started adding value through automated testing, pair programming, and refactoring. Always Add Value. Create and Innovate.

You’re a great help when it comes to offering assistance to other parts of the business. You’re usually the first one to volunteer, especially for customer support problems. Delight the Customer.

You bring an awesome attitude to the team that everyone really appreciates. You’re able to take tense situations and quickly defuse them through a steady demeanor and extremely well timed and apropos quips. Have Fun. 

Things that you should start or stop doing

I’d like to see you take on more of a leadership role in the Communities of Practice. Currently, you’re doing a great job of participating and promoting the CoP, but I’d like to see you move forward with leading the rest of the team through new exercises. Be Fearless, but Not Reckless. Have Fun.

The downside of moving quickly through test scripts is that you tend to stick to the script. In order to ensure maximum quality in the product, I’d like to see you be more thorough in the testing. Either add more test cases to the scripts or work to improve your freestyle testing. The goal here is not only to run the test script, but to really ensure quality in the feature under test. Always Add Value.

As someone that is interested in continuing down the path of Quality Assurance, I’d like to work with you get some formal training in place around QA processes and techniques. There are a lot of opportunities to quickly find new and better ways to test our product and make that testing more effective and efficient. Always Add Value. Create and Innovate.


Without question, you have embraced the new development processes and practices enthusiastically. Without your help, we would not be nearly as successful as we’ve been.

You’ve adapted extremely well to the new development process. Not only did you make the transition to the product engineering team, but you made the transition to a completely new process as well. Additionally, you haven’t just been a passive participant in the new process, but you’ve actively engaged in the process and made suggestions that lead to real improvements.

Congratulations on winning the Windows Phone when you participated in the developer event on campus. Few people are willing to even put their work in front of their peers, much less win a first place prize for it. Keep up the good work.

Previous Goals:

Grading Scale:

  • Not Applicable
  • Not Met
  • Met
  • Exceeded

Goal 1:

Improve quality initiatives and lead the effort in achieving higher quality. This can include anything from continuing to write unit tests yourself, as well as teaching others on the team about what makes for a good unit test through formal instruction or simply through peer reviews. This could also be writing integration tests, helping to better structure test scripts and test cases, driving process improvements, implementing better SVN procedures, recommending architecture improvements, or any number of things. As you help drive quality initiatives, keep track of what you do and write a blog post (or just email me if you don’t have a blog) to let me know what you did, and what impact it had on the team and the quality of Qualtrax.




You have, unquestionably, been driving quality initiatives through your own work and through pairing. I’ve seen you work on unit testing, integration testing, UI testing, and refactoring efforts. You’ve even taken this a step further and begun to lead the team in broader discussions about the Qualtrax architecture.

Goal 2:

Further knowledge of object-oriented software design patterns and their proper applications. Choose at least three patterns from the “Gang of Four” book (Design Patterns: Elements of Reusable Object-Oriented Software) and study them. Either write a blog post about each one (can be sent to me in an email if you don’t have a blog) or present all of the patterns to the rest of the team, including internal development.




This was started a little late in the year, but I like what you’re doing. Getting the Head First Design Patterns book is a great start into working with patterns. Learning about patterns is great, but now we need to learn how and when to apply the patterns. I suggest creating small, sample apps to help learn about the pattern, which it sounds like you’ve already started doing.

Goal 3:

Learn new User eXperience (UX) techniques that could be used to improve the overall Qualtrax UI. One of the biggest complaints I’ve heard about the Qualtrax UI is that the administration of parts of the system make it hard to accomplish the task at hand. Any work you could do to help alleviate some of these problems would be helpful, and I’m fairly confident we’d be able to get some of this work on the backlog during the next six months. Learning about prototyping, consistency rules, usability studies, personas, or even jQuery UI tools, are all things that will help move us in the right direction. This one will be hard to measure, so I’m going to have to enlist Ken’s help to provide guidance on how well you’re doing here.


Not Applicable


While we all agree that UI and UX improvements are much needed for many areas of Qualtrax, the primary focus for the development team during this review period was getting 4.3 out the door. This made it difficult to get any work done that wasn’t directly related to getting bugs tested and fixed. Furthermore, I made commitments that I failed to follow through on. We’ll bring this goal back for the next review period.

Goal 4:

Obtain functional knowledge of the MVC framework (specifically .NET MVC) relating to how it could be used for our purposes. Use books, blogs, or other people (feel free to schedule several meetings with me to download my knowledge of MVC) to study the MVC framework. Talk with the team to figure out how it might fit into our current product. Send me a proposal of how we can move forward with MVC in the Qualtrax product.


Not Met


This was simply not a priority for the product during the past six months, and no time was made to research MVC. We’ll try this one again for the next review period.

New Goals:

Goal 1:

Improve understanding of IoC principals and implementation using containers. This goal will be the focus of the first three months. You should have demonstrable material that shows an implementation of an IoC container used inside of Qualtrax. You should present this to the team to show the benefits.

Goal 2:

Obtain functional knowledge of the MVC framework (specifically .NET MVC) relating to how it could be used for our purposes. This didn’t get done during the previous review period, but it’s interesting and important enough to give it a shot for the upcoming review period. Use books, blogs, or other people (feel free to schedule several meetings with me to download my knowledge of MVC) to study the MVC framework. Talk with the team to figure out how it might fit into our current product. Send me a proposal of how we can move forward with MVC in the Qualtrax product.

Goal 3:

Create and track quality metrics. In order to see what effects our quality efforts are having on Qualtrax, we need to identify, track, and display meaningful metrics. Ultimately, I leave it to you to determine what those metrics should be, but some ideas might be to track total bug reports submitted, what stage of development those bugs are submitted at (the earlier the better), number of bugs that are reported that are and are not covered by an existing test script, etc. This will be measured by you sending an email to the team telling us what we’re going to track, how we’re going to track, what effect successfully improving said metric will have on the product, and why that metric is important. Additionally, displaying the metric and the trending data for that metric near the task board would be great. I’d like to see at least three new metrics in place by the end of this review period.

Goal 4:

Improve understanding of MVC framework and implementation. This goal will be the focus of the second three months. You should have demonstrable material that shows an implementation of MVC in Qualtrax. You should rewrite a select number of screens in Qualtrax and show the team how we could effectively use MVC moving forward.

Peer Feedback:

What does Sir Mix-A-Lot do well?

  • He is a great team player.
  • He is always excited to learn new things.
  • He is genuinely passionate about software development.
  • He is fantastic to pair with.
  • He has a great sense of humor and brings fun to anything he is involved in.
  • He is a test script killa.
  • He is willing to dive into testing and to learn how or why something is not working as intended.
  • He does a great job reviewing test scripts and finding errors in the scripts themselves. I’ve personally sent in several test scripts for review that had problems that I didn’t catch, but he almost always catches them.
  • He brings a fun element to the team and helps lighten tough situations.
  • He is, by far, the most knowledgeable developer we have with regards to the product. You can ask him any question about the features or the code, and he probably knows the answer right off the top of his head.
  • He is quick to volunteer his help when asked.
  • He is the best manager of the development resources that we have, and has done a lot of good work setting up the new server and development environments.

What should Sir Mix-A-Lot start or stop doing?

  • Learning about the recurring issues that the support team faces could help the developers avoid those in the future.
  • He needs to be more aware of how his communications come across to others. Sometimes his comments can be interpreted as condescending to teammates. I don’t necessarily think that is how he intends it, but the tone and style could use some work.
  • Sometimes when I ask him a question I don’t fully understand the answer. And then again sometimes when I ask for him to repeat or explain in more detail he seems to get annoyed at the fact I didn’t get it the first time. This does not happen all the time, but sometimes it is a deterrent for trying to get more information out of an answer.
  • It seems like he spends a lot of time working on the metrics for the team. A better use of his time might be researching tools to automate more of that part of the process.
  • It would be great to see him work with the support team more often. I haven’t seen him do this very much, but when I do see it, it has been very positive. It would be helpful for him to learn about the reoccurring issues that support faces.

Overall Rating: OUTSTANDING

Rating Scale:

  • Unsuccessful – Employee is not meeting job expectations.
  • Variable – Employee is not consistently meeting job expectations.
  • Successful – Employee is meeting job expectations.
  • Strong – Employee is meeting job expectations and going above and beyond in some aspects.
  • Outstanding – Employee is going above and beyond job expectations in all aspects.


In all things that you take on, you exceed expectations. You propose solutions instead of dwelling on the problems. You embrace and demonstrate the core values each day you come to work. 


I have read and understood the information in this review and discussed with my manager.

Employee Name Date 

Manager Name Date

Additional Employee Comments:

About the Author

Ryan Hagan has worked as a software development manager for the last decade, and has dedicated himself to raising the bar for software development everywhere he goes. He cares deeply about doing things right and doing things well. He takes a non-dogmatic approach to Agile software development processes and great development practices. In addition to software development, he’s spent many years dedicated to leadership activities and developing other leaders. Ryan is passionate about creating great places to work because he wants to work in great places.

If you have any questions, please feel free to reach out to Ryan or visit his LinkedIn page.  

Rate this Article