Developer KPI: How to define and measure

Reviewing performance reviews

From giant corporations through to small, one team development shops, good company management are always keen to make sure that their people are both productive and satisfied with their contribution. A huge part of that in most cases will involve having an on-going review and feedback process with every individual.

As with most small companies, we’ve always tried to be attentive to every person on our team, providing regular feedback on their performance and teamwork, noticing their improvements, encouraging self development, etc. and adjusting their rewards accordingly. But, as with most growing companies, there came a time, when just being attentive wasn’t enough and our old, informal way of doing staff reviews had to evolve… into a rock-solid process. That’s exactly the change we’ve been going through over the last year or so and something I want to share about with you now.

The review process doesn’t have to be hard, let me show you how we do it.

Have you ever found yourself procrastinating on that one conversation you know you should hold, or on giving a staff member some important feedback to address some misalignment with your behavioral expectations? At the same time, how do you keep track of everyone’s performance and take notice of all the things they do, big, small, good and bad, that either need to be recognised and given praise for, or addressed as unacceptable?

Both of these questions need to be met with a process. Where you lack a deliberate process for recording performance indicators and handling feedback conversations, problems will begin to arise; it may be acceptable for a while with a smaller team, but when you start to grow and the number of conversations you need to hold increases proportionally, that’s when it becomes a problem. We came up with our own process for handling this, which is simple and very practical. Let me describe it for you.

First things first – define what is important for you

When it came to deciding on KPIs for our team of developers, we didn’t want to reinvent the wheel and thought that it was likely someone had already done the research and established some industry best practices… turns out it’s not that simple. In short, after hours of research and a number of conversations, we came down to an agreement that we needed to use a whole set of criteria that are important to us and not just 1 or 2 specific KPI’s (some people say that lines of code is a good KPI for example, it’s pure nonsense though). So, we decided that our main KPI for developers would be to monitor that projects are getting done according to the standards of the team, which we defined as follows:
– Write good quality code
– Deliver on time
– Keep balance between estimated vs. actual time spent
– Care for the project and the team (eg. be responsive, respect the PM and the rest of the team, be attentive at project meetings, etc.)
– Keep all technology and company guidelines
– Track time
– Self development; ensure that personal growth is present and visible

These are some of the things that are important to us, when it comes to the standards of the team. Which are yours or what would you like to add to this list? It would be great to hear your comments on it.

So the first step involved understanding and defining what is important for you. Now, on to the actual process itself: how to regularly review a large team, gather feedback about their performance, and provide this feedback to them.

Our defined process consists of 4 elements: notice, record, review and give feedback

If you really care for your team, you want to spot everything that is exceptional and worthy, to give them praise for it, as well as anything that is unacceptable for you and for your company culture, to encourage change. It’s not easy to do, but it’s a duty inherent in good leadership.

Our in-house system for observing and keeping track of these sorts of performance indicators is built around these four elements: notice, record, review and give feedback.

1. Notice, Record
   1. We have a spreadsheet with a list of all of our developers on it, where project managers can leave their feedback about good and bad experiences they have with their teams on different projects
   2. On a monthly basis our HR manager reminds the project managers to update this document for the previous month
   3. We also have a more detailed form for every developer individually that gives every manager and team lead the ability to evaluate a developer’s professional and teamwork skills. During the first ten days of each month, this form is filled out by team leads and managers for the individual developers they’ve been working with. It consists of seven questions, which are answered using a 1-10 scale and include the following: 1) How would you evaluate the developer’s work/code quality within the project (projects)? 2) Did they achieve a good balance between estimated and actual time spent on projects? 3) How would you evaluate their teamwork/assistance? … and so on. We have set specific guidelines as to what 1-3, 4-6, 7-9 mean, and which criteria each number requires. These are directly related to the standards of the team, as we defined them (see above).
   4. We then assign each developer a grade for each question formed by the average scores they received from all the PM’s and team leads they worked under that month.
2. Review, Give feedback
   1. Our HR manager has a document with a list of all our developers and the date when each person was last reviewed.
   2. Prior to having a review conversation with any of the team members we read the review document (mentioned in point 1a.) and ask relevant managers, team leads or the CTO for feedback about this person.
   3. Then we review the personal forms from PMs and team leads (mentioned in point 1c.).
   4. After the documents are updated (during the 1st week of every month), Viktor and I (CEO and COO), start holding conversations with those who have not been reviewed within the last 5-7 months. This happens during every second week of the month.

As a result, performance review is an ongoing process and each person typically gets reviewed 2 times a year.

A work in progress

This is what we do. We don’t make any claims as to the perfection of our process. We’re still looking for ways to improve and simplify it, without sacrificing on the quality of the feedback. We feel though that it offers a good, comprehensive starting point for implementing a detailed, accurate and regular process of performance review.

What are your thoughts on this? Which things would you improve, change or add? If you feel like there are some blind spots that we didn’t take into account – feel free to leave a comment and let me know. I’d be happy to hear from you 🙂