Performance reviews are a common and well-established practice in almost all companies, from startups to large enterprises.

In this post, I’ll give my take on how to conduct an effective performance review for developers. I’ll provide general guidelines that apply to any profession. In addition, I’ll provide some tips that apply specifically to conducting performance reviews with developers.

What Performance Reviews Do

Regardless of the type of company you work for, performance reviews accomplish the following:

  • The employee can give feedback about their general well-being and attitude toward their particular position and the organization in general.
  • The manager can provide the employee with direct feedback on their performance. This includes whether the employee met their goals in the previous year or not.
  • They allow the employee and the manager to align expectations for the year to come.

Setting Up the Stage

First thing first, both parties should do their homework before conducting the performance review. The developer should come with a clear agenda regarding whether they met their goals of the last year, their accomplishments, things to improve, etc. In a similar fashion, the direct manager should come with an estimation of the developer’s performance, whether goals were met, and so forth.

Most companies conduct performance reviews on an annual basis. This usually proves sufficient. However, some companies opt for a biannual review process. From my experience, I recommend a biannual review process only for underperforming developers that you want to keep close tabs on. For most other scenarios, an annual review is enough.

Manager Prep

The manager should check the employee’s file for the list of goals that were set in the previous performance review. The meeting should revolve mainly around those goals, whether they were achieved, how, and to what extent. To make the discussion more productive, the manager should come with specific examples.

For instance, if you want to discuss the number of bugs the developer introduced in production code as a point for improvement, it’s best to come with a list of specific bugs. Likewise, if you want to discuss a period during the year when the developer delivered on time and on scope and generally performed with flying colors, it’s best to talk about specific features.

In any case, add concrete examples for any goal that has been set. Accompany it with a verbal assessment of whether the developer has met the goal.

Setting Goals for the Year to Come

Another key purpose of a performance review is setting goals for the upcoming year. It’s vital to set the goals properly. Otherwise, the developer and management won’t be able to assess the performance in the next review. To make the goals meaningful and thus possible for evolution, each goal should be:

  • Specific: Pinpoint as narrowly as possible what exactly you are expecting from the developer.
  • Measurable: Set only goals that you can measure. For instance, “85% of features delivered on time” is a measurable goal. “Object-oriented code with best practices” is a less measurable one.
  • Actionable: Goals should be actionable for the developer. For example, “increasing the velocity of the R&D department” is not a goal that the developer can be fully responsible for on their own. There are other stakeholders as well, such as product managers and the DevOps team. This goal is tangible only if all parties do their part to achieve it. This also includes other developers. On the other hand, a goal that says “cover at least 90% of your code with unit tests” is an actionable goal for the developer.
  • Realistic: There’s no point in aiming for a pie in the sky. For example, you can’t expect a junior developer to develop a full product from scratch in no time.
  • Time-bound: You should be able to assess at the next performance review whether the goal was met. Goals such as “become a senior developer” are not time-constrained and thus are not a good example. On the other hand, “learn Golang and create one microservice with it within three months” is.

The Performance Review Meeting

The best way to start a meeting is by letting the developer speak first. This way you’ll be able to add some data to the homework you did, which will enable you to fine-tune your message to the developer.

Discussing Goals

Start with the previous year’s goals. Check what was done and what was not. What are the parts we want to keep and what should be improved?

The meeting itself shouldn’t happen in a hostile atmosphere. Even if the developer didn’t meet the goals set, it’s best to show the data as it is and lay down the facts instead of berating or being angry at the employee. Something along the lines of, “Here is what we have expected and here is what was delivered. This is not good enough. Here is what we expect now,” should work.

After discussing the previous year’s goals, it’s time for this year’s goals. Try to convey them in the clearest way possible and ask for feedback if anything is not clear. Aligning the expectations regarding those goals is critical for the upcoming year’s bottom line.

Freewheeling Discussion

After discussing the goals, allocate some time for general conversation. Ask the developer how can you help them achieve their goals, what is on their mind, what obstacles they face in day-to-day work, and similar.

Wrap the conversation up by stating whether you are happy with their performance for the previous year. It’s important to every employee’s sense of job security to understand where they stand.

Follow-Up

Lastly, prepare a written summary. It can be emailed to the developer and used for future follow-up. It’s useful to go back to this summary, for instance, every time you think that the developer is going a bit astray and you want to straighten things out.

Again, this shouldn’t be done in a brutal or hostile manner. It can be something like, “We discussed this in our performance review and I still don’t see an improvement in this field. It’s important for me that you make a change regarding this.” Open and honest communication is the key to fostering trust and understanding between the manager and direct reports.

Wrapping Up

Effective performance reviews can boost the productivity of the developers you manage. A performance review is undoubtedly an important tool in every manager’s toolbox. For a performance review to be effective, both parties need to do their homework before the meeting.

During the meeting, discuss and analyze the previous year’s goals. Include what went well, what didn’t go so well, and what went completely wrong.

After discussing ways to improve and what exactly happened, it’s time to move to this year’s goals. Those goals should be as clear as possible for both the manager and the developer, according to the criteria defined above.

Finally, to bring the improvement home, it’s important to follow up on the performance review action items via a written summary and make sure that the things are done.

Looking Forward

In this post, I’ve discussed general guidelines and procedures. But I couldn’t discuss your specific situation with a developer because I’m not familiar with it. If you need some advice regarding a specific performance review or management issue, or if you want to learn from the experience of others, a good place to look is LinearB’s community for leaders—Dev Interrupted.