tags:

views:

466

answers:

6

What criteria do you rate your developers on when doing their yearly reviews? We are looking to improve our process more than "we feel you did a good job, here is a raise!"

We were thinking something like:

  1. Attendance
  2. Teamwork
  3. Quality of Work

We are a .NET / C# shop if that helps.

A: 

Speaking as a developer and not as a manager:

You may have included this in quality but I would definitely look at their code from the beginning of the year and code at the end of the year and try to figure out how many times they created a custom class for the express purpose of abstracting a certain functionality that they used repeatedly. In my opinion that's a great way to see if a programmer is trying to improve their methods and it should definitely be rewarded.

Spencer Ruport
+2  A: 

Here is the structure where I currently work:

  1. Goals and duties:
    Project Work, Support Duties, etc.

  2. Performance Review:
    Performance summary, quality of work, quantity of work, commitment, judgement, relationship building, core values, etc.

  3. Development Plan:
    Goals for the next year.

For the first two items we have a 4 point scale of exceeding/meeting/partially meeting/not at all meeting expectations in each area as well as an explanation for that rating both from the developer and the manager.

JB King
+12  A: 

Interesting you ask this, as just today I read an article by Joel Spolsky about how to reward developers.

In my organization, we don't look at attendance at all. Developers really, really hate to be micromanaged. As the aforementioned Joel mentioned in a different article, one of the perks of being a developer is not having to ask to go to the bathroom. In other words, we don't like to be watched.

We use objectives and goals to track developer success. We look at deliverables, talk to peers and customers, and so on. It seems very simple to me, actually. If someone isn't good, we don't wait until the yearly review to figure it out.

Robert S.
I agree with this. I frequently have to just sit and think about a design before I start coding. When I'm in this frame of mind I certainly don't look productive.
Spencer Ruport
+1 for "talk to peers" but I'd want a lot of those peers to be from other departments - how PMs, sales, ops percieve you is extremely important for fostering a co-operative company-wide atmosphere imho
annakata
Another note of agreement, I absolutely think you have to keep it simple, as was pointed out, developers (speaking personally) hate being micro managed, and having a long list of things to tick off feels like just that.
RSlaughter
+1 for the article and making me go to joel spolsky blog, its amazing!
DFectuoso
+6  A: 

Three major categories worth 15 points each, which the manager scores:

  • Hard skills (does this person have the skillset expected of someone in their position, e.g. "Senior Developer"?) 1-10 being "not so much" to "yes", 11-12 being "great", 13-15 being "best senior developer ever"

  • Improvement/performance (has this person improved their value in that position, and to the organization, since the last review?) - 1-8 being "regressed" to "maintained altitude", 9-15 being "small improvement" to "massive improvement"

  • Soft skills (5 sub-categories such as: does this person have a good attitude? does this person facilitate teamwork? etc.) each of the 5 is ranked on a scale of 1-3

Add up the scores and distribute them on a curve graph, use that to determine compensation/raise/etc.

Rex M
+8  A: 

Here is a template I use as a development manager. Please note that the categories are mandated by the company and are scored on a 1-5 scale (5 is highest) and then averaged for an overall score. The interpretations of the categories are my own as applied to a programming team.

Job Knowledge: Is an expert in both the technology and problem domain relevant to his job. Stays on top of changes to technology and leverages them to improve the timeliness and quality of his work without needing a supervisor to push.

Accuracy: Cases sent to testing by this programmer are almost never kicked back by the testing team for obvious problems. The code written by this programmer almost always has unit tests written that are sufficient in scope and code coverage. This person does not have to be reminded to go back and add unit tests and almost always writes test cases before writing new code.

Work Habits: This person understands and manages priorities extremely well without a lot of follow up required by the person who assigned or supervises the task other than status updates which should be timely, concise and communicative. Willing to put whatever effort is necessary in to get the job done.

Problem Solving/Decision Making: When obstacles present themselves, this person takes ownership and removes those obstacles to remain productive, but also knows when to involve their supervisor to get assistance in getting to the end of that task as expediently as possible. Further, they are an active force to removing obstacles for others. This person has a solid grasp of what issues can be deferred and which need to be cleared before progress can continue. This person is a frequently the catalyst that provides momentum to a project.

Interpersonal Skills: When conflict arises, this is the person who is the calming influence and often steps up as a mediator when tempers flare. In stressful situations they calmly assess the problem, avoid personalizing issues and focus on a solution. Others enjoy working with this person and they actively engage in behaviors that improve team cohesiveness. People frequently request this person to work on their projects.

Communication: Communicates in a manner that is timely, relevant and concise. This person goes out of their way to make sure that others are informed about things that are relevant to them and speaks up frequently as a proponent of more communication.

Leadership: Promotes the corporate and departmental values even when the supervisor is not present. Is a source of peer pressure for doing things the right way instead of the easy way. Does not shirk confrontation when it needs to happen. Boldly steps out of comfort zone to stand up for integrity and quality.

Customer Service: Is the person in every meeting that brings up the customer. When customers have complaints or are being difficult, they instinctively take the customer's point of view and start trying to understand and solve their problem instead of being dismissive, even when the customer is not around. Generally known as an advocate for the customer, especially difficult customers. The customer can mean both internal and external clients, but when these conflict this person always sides with external clients.

Training: Completed training plan with vigor and enthusiasm and exceeded it where possible. Frequently suggests training opportunities for others. Volunteers and takes the initiative to set up training for others in the organization on topics that they are familiar with. When receiving training, this person eagerly tries to distribute their knowledge out to others.

When I score them, I reserve the highest score (5) for people that not only exemplify the particular trait, but are also are a catalyst for improving others in that category.

A word of warning: Every business book says this, but it bears repeating. Beware of metrics based performance evaluations. You will get EXACTLY what you measure and often in ways that are not what you'd expect. Programmers are especially good at finding ways to meet metric driven goals without furthering the underlying goal of the metric. For example, how many ways can you think to improve your LOC (lines of code) number per week if you knew it would affect your compensation that don't necessarily get the project out the door any more quickly?

JohnFx
When I worked in support, the boss would work out the stats on how quickly a problem was solved (2hr/4hr/1d/1w/2w/1m) and it was fed into our reviews. Thus the big, nasty, awkward problems that often had most impact were dropped because they went over 1mth. Boss just couldn't see the issue.
CJM
Metrics scare me when evaluating technical talent as they are very hard to measure and often easy to achieve without accomplishing the underlying goal. I prefer to poll the people they are supporting to get a more realistic idea of how helpful and efficient they were.
JohnFx
+1  A: 

Get a copy of Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers) by Johanna Rothman (Author), Esther Derby (Author) and adapt the processes they outline for reviewing technical staff to your shop - you will get happier and more skilled developers as a result.

For instance they suggest reviewing developers monthly and aggregating the results for the annual review. This approach bases the annual review on empirical data rather than what ever the developer did or didn't do to please you in the last month.

Both the authors have websites you can mine for articles and blogs.

kloucks