CXO

Real-world tips for developers conducting performance reviews

When evaluation time rolls around, team leaders often get tasked with reviewing other developers--sometimes at the last minute and without much guidance. These tips will help you deliver effective performance reviews even if the situation isn't ideal.


You’ve been asked to assess the performance of other developers as part of an annual appraisal process. And odds are, you're not looking forward to it. After all, performance reviews can be difficult to complete, especially if you know they might be used in determining who is promoted to senior developer and who is relegated to less important projects—or worse, who is deemed extraneous if your company is facing reduction in staff.

In the best of worlds, you know ahead of time who you're going to evaluate. You'll have worked closely with them, and you'll have had a chance to gather specific, relevant information on their skills, abilities, and knowledge throughout the year. But in the real world, you could be handed a set of performance reviews to complete in two days for developers you’ve only seen in the break room. Your task will be doubly complicated if you don't have much experience executing a performance appraisal and are given little training or guidance on how to complete the review. Let's look at a couple of scenarios that will illustrate ways you can provide useful and fair assessments of other developers.

Scenario one: All the time in the world
In the first, and more reasonable, scenario, you know months in advance who you’re evaluating and can make plans with the employee that include a skill development strategy. Work with the employee to see where he or she would like to be. You should be consistently documenting performance throughout the evaluation period. Just make simple notes to yourself and drop them in a file. Do this at the time of the event and do not rely on your memory. Here are some specific guidelines:
  • Set simple and specific goals in advance with the developer. Measure progress and change goals when appropriate throughout the year.
  • Gather the right data and automate the collection process whenever possible. This type of “hard data” will reduce the likelihood of reviews seeming subjective. Three sets of data most useful to a development team leader come from the following sources:
    Metrics from a source code controltool: Things to track include code metrics and quality.
    Task history, including estimate vs. actual: Track tasks averaged over time, with more than one person providing work estimates. Gather history on more than one project too. How close is the actual to the estimate for this individual, compared to others? Keep in mind that failure does not necessarily mean underachievement but perhaps an inability to challenge a bad estimate.
    Defect-tracking reports: Measure how quickly defects are analyzed and resolved and identify which developer coded the problem.
  • Consider customer satisfaction ratings for specific applications. Have users evaluate specific modules or screens. Separate production-related application issues, such as downtime due to network issues, from the actual design and subsequent product.
  • Encourage and expect participation from the developer you’re evaluating. Ask what he or she thinks of certain situations you've noted in your assessment. You may find that some of these performance concerns have reasonable explanations you had not considered.

As you evaluate this information, you shouldn't be looking for flawless performance but rather considering how this person has done relative to others in your shop.

Scenario two: No time to lose
In the second scenario, you have little time to prepare for an evaluation, and you barely know the developer you’re expected to evaluate. In this case, here are some things you can try:
  • If you are completely unfamiliar with a developer's abilities, speak up. Talk to your manager or human resources. Better yet, find a developer or manager who is familiar with this person’s work and suggest that he or she do the review. (Failing that, you can possibly ask this other person for his or her insights on the employee you must evaluate.) Keep in mind that the employee doesn’t want to be evaluated by a stranger any more than you want to evaluate someone you don't know.
  • If there’s no way out, engage the developer you're evaluating. Look at his or her accomplishments list, goals, and improvement plans for the past year. Rely on what is documented and place some faith in the honesty of the developer’s self-evaluation until you have your own set of experiences by which to assess them. If you will continue to be responsible for evaluating this person, develop a specific plan for the upcoming year and monitor progress at regular intervals. Better yet, ask for monthly status updates to stay in touch with the employee's progress. Don’t let another year pass without knowing his or her work.

In all cases
The appraisal process is an ongoing one. Here are some of the things you should be considering about each developer before and during that process:
  • Set specific, measurable goals related to upcoming projects, organizational objectives, and desired career paths. Include provisions for formal and informal training.
  • Be aware of any mentoring that's going on. The employee standing behind other developers, guiding them through the development shell or showing them how to use the IDE might not appear in the stats as being more productive than other teammates, but he or she is leading the team to a greater ability to produce. When you notice someone at the helm, jot it down.
  • Rate each developer according to skill level. It’s not fair to expect the same output from a junior developer barely out of tech school as you would from a senior developer who has worked for the company for five years and single-handedly designed the app that runs the accounting department. Rate each developer according to his or her job description.
  • Observe whether the developer plays nice in the sandbox. Functioning well as part of a team is an important characteristic in nearly every environment. You should document this throughout the year and include no surprises for the developer being evaluated.

Here are some of the things to consider about the evaluation mechanism and process:
  • Know the value of the evaluation process within your company. Is it actually used for tracking development or for determining the size of raises and deciding who gets promoted? Is the annual appraisal a mere formality, something collected and stuffed in a black hole of a filing system, never to be seen again? Don’t waste time writing multiple-paragraph narratives in the comment section if a line or two is all that’s expected, especially if you know nothing will come of the work.
  • Make sure that you're sufficiently trained on the performance appraisal process. Have you been given in-depth training to learn how to use your company's performance appraisal system? You don't want something you write or score to be misinterpreted simply because you didn't understand the implications of filling out some part of a form.
  • Determine what existing documents you can draw from. Gather last year's appraisals, job descriptions, company objectives, memos, and status reports.
  • Know when you’re in over your head. If you're experiencing an unusual degree of anxiety during the review process, your internal alarms may be telling you that you're out of your depth. Seek help and advice from others. Supervisors (even other than your own) and peers in your situation may be a valuable asset as you struggle with the process.
  • Carefully consider how you address negative performance. By all means, you should include performance deficiencies in your evaluations. It’s only fair to the team members who shine. But make sure that you touch on these issues in a manner consistent with HR and legal policy. Furthermore, if you give an unfavorable rating to an employee and you haven’t covered the issue with the employee already, something's wrong. An annual review shouldn’t include negative surprises.
  • Be fully prepared to defend high and low ratings. If you can't support your reasons for assigning a particular rating, you shouldn’t assign it in the first place.
  • Communicate with whoever reviews your assessment before you meet with the employee to discuss it. Your manager and HR should stay in touch on every evaluation. That way, they can help guide you through the sticky spots.

An ongoing process
It’s certainly possible to provide members of your development team with effective, useful evaluations that inspire them to greater success at your company. The best appraisal system begins long before the day of the official review. Feedback, whether negative or positive, is better received when you’re a regular presence in the developers' workday and when you express your desire to see them move forward in their career.

Editor's Picks