3

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!

  • 1
    @klenwell: In the startup I work at we use soft, non-individual metrics. How many bugs were created vs. how many were squashed? What were the buggiest components of the software? How productive does the team feel? How do we feel about people, communication, and workflow? How spot-on were our complexity predictions? What’s our code coverage? — They do not measure individual performance (as work in our context is very collaborative), but the quality of our team effort. They cannot be used to prescribe a clear cut (and deeply flawed) up-or-out decision, but highlight where the team can improve. – Roman Feb 2 at 13:29
  • 1
    Reducing "performance" in knowledge work down to 1 or a few numbers is doomed to be a poor metric, to outright failure, or even to gaming by savvy manipulators. Instead, use written evaluations. Throughout the course of the year, write about each project as though it were a movie review, solicit input from your users/customers, name contributors and their achievements, discuss the impact of the work on the organization as whole and how it sets the stage for further work. Is that "objective"? NO, but it has far more meaning and usefulness than a dumb set of KPI numbers (or S.M.A.R.T goals BS) – teego1967 Feb 2 at 14:29
6

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.

  • 3
    How does he know those things are working/improving if he's not measuring anything? (And if he is, then I would posit that those should be the KPIs that management is demanding). – dlev Feb 2 at 7:00
  • 3
    The mindset for most devs would be: If we are delivering results in a timely manner, why would we need to measure it? – Juha Untinen Feb 2 at 8:20
  • @JuhaUntinen Why would anyone want to improve, ever? – Roman Feb 2 at 13:22
  • 1
    @diev, he can measure things, just don't go through the KPI charade. Every developer can see right though it. Like I said, measure things that he can already measure, like bug counts, feature counts, release slippage, scope cuts, etc. You want a smoothly running shop and you do that by removing as much friction as possible. Simplify workflows, don't complicate them. Keep clients away from developers if at all possible, etc. KPI's add friction because the developers are busy figuring out how to game the system. Developers improve by knowing more things, not minimizing steps mechanically. – Tombo Feb 2 at 14:31
  • 1
    @diev, also, the most efficient thing you can do to a codebase over time is make it intuitive, modular and maintainable. If you have a large crazy, overly complex codebase, you will be paying for it for decades. Bugs will be harder to find, new features will be harder to implement and more prone to bugs, leading to hacky code, and it's a vicious cycle. How do you measure how maintainable your codebase is? You certainly don't do it by "demanding" KPIs. – Tombo Feb 2 at 14:44
1

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.

  • There were company goals presented. They makes sense and I'm behind them. But, yes, the question of how this information is going to be used was not explained and is a concern. I'll seek clarity on the point with upper management. Your points are well taken. Thanks! – klenwell Feb 2 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.