What are some sane KPIs for a team of web application developers?

Question

I was tasked this week by executive management to come up with some annual KPIs (Key Performance Indicators) for our development team by the end of the month. They also want individual developers to establish their own personal KPIs.

Do you have any suggestions for sound useful KPIs for a team of mostly Rails developers?

I'm thinking about things like the code quality metrics you see on Github repos. At the same time, I have some reservations.

Over the last year, in the absence of KPIs, our team has worked successfully to sharpen our development practices, accelerate the delivery and improve the quality of our applications, and build real esprit de corps. I worry that this is going to interfere with that and (to cite a new term I recently came across) run into Goodhart's Law.

In my preliminary research, I also came across this quotable line on the topic:

If there ever was a certain way of killing morale in a startup it was by introducing KPIs and calling them KPIs.

We are still a relatively small and young company with what we like to think of as a startup vibe.

I'm prepared to push back against the initiative. But I thought I should give the idea a fair hearing. Links, suggestions, arguments against the whole idea are welcome. Thanks!

Answer 1

In my experience, your intuition on KPIs is spot on. It will kill morale and they will lose respect for you professionally. It sounds like management wants to turn a low turnover, appealing work environment into a bureaucratic, soul sucking hell hole.

I've been through 2 of these myself. It always ends with all your tops leaving within 2 years and eventually leaving you with a bunch of people who will put up with KPIs because they have a hard time finding other jobs. Also, even mediocre developers are smart enough to game any system you try to manage them with. In my experience, this happens often after an acquisition from the new parent company, or a new executive team.

The adage goes, "managing developers is like herding cats." My best advice on that is to give them ownership and accountability of a domain, and guidance on how to prioritize requests. Your tops can all self manage (and probably prefer) while your mid and entry levels might need more guidance, but KPIs aren't the answer. That's call center stuff. Developers are creatives. They are also good at math, which is a very rare pair of traits. The worst thing you can do is manage them like clock in workers.

If you absolutely must metric something, select something the company should really care about, like new bug counts, or bug to new feature ratio.

Over the last year, in the absence of KPIs, our team has worked successfully to sharpen our development practices, accelerate the delivery and improve the quality of our applications, and build real esprit de corps.

You've found something that works for your team. Keep doing that until it doesn't.

Answer 2

Do you understand how this information is going to be used? The immediate and long-term goals of upper management? This basic understanding should help guide you in determining what metrics to monitor as well as how to report them.

For example, if executive management is interested in overall department performance you can report the information in such a way as to prevent singling out any one individual on the team. If this is the goal then you are much more likely to get buy-in from the individual team members.

However, if this information will be used at the individual level in performance reviews, to determine advancement, compensation, or potential layoff; then it becomes a much more difficult sell to the team.

That being said, individual metrics are important and can be very valuable if used correctly; so you should be collecting them. But in my experience, an individual's metrics should be treated as confidential just like pay, performance reviews, and HR files.

While I am a strong proponent of using metrics and KPIs for development teams, there are many caveats that are often overlooked. As a result, the KPIs, regardless of what metric they measure, tend to be taken as 'gold' when in fact they are derived and contrived measurements that are directly impacted by outside forces that are often not measured or understood.

In simplest terms in a manufacturing environment if I know that a given machine can produce 1,000 widgets in an hour that is a concrete, discrete measurement. There are 1,000 repeatable tasks that are exactly like the previous task. Each one a duplicate of the others.

The bottom line is that software development has never been exact duplication and replication of previous tasks. Each task, requirement, developer, QA resource; nearly every aspect varies from task to task. Treating metrics as 'carved in stone' is like comparing apples to oranges.