What KPI's or OKR's do you use for individual software engineers?

Question

As a company, we're trying to push more quarterly OKR's into the individual level. We've had success with quarterly goals at the team level (IE code coverage, # of successful releases, up time, % crash free users, etc), and we have long term professional individual goals for career growth. However, we're new to pushing goals down to the individual quarter to quarter. What are the metrics you use to track engineers growth and achievement quarter to quarter?

Before going any further, I should recognize some of the similar questions that have been asked on this topic, and my agreement with the negative answers -

• I whole-heartedly agree that tracking lines of code is a horrible, terrible metric. There's probably a 100 reasons for this, a few of them included here: https://pm.stackexchange.com/a/8970/27888
• I also agree that attempting to track bugs written / solved / etc. is an anti pattern. Good answer here that I agree with: https://pm.stackexchange.com/a/5290/27888
• I asked in a different question about tracking story points achieved per engineer. I'm still mixed on these answers, but worth calling out the conversation exists: Are story points achieved a good individual quarterly goal?

So given all the things that are bad ideas for showing / tracking individual achievement and growth quarter to quarter, what are the right ways to do this?

Answer 1

TL; DR- Tie individual KPIs/OKRs to developmental goals unrelated to the product/project they are working on.

My advice is based on a successful implementation one of my own agile mentors did and I hope to do someday with one of my clients.

They overhauled the entire HR review process and put in place a 50/50 model.

The first 50% of your review is based on your team. If your team scored a 36, you get a 36. If your team scored a 2, you got a 2. Teams were measured on the delivery of value to the customer. This is a whole other answer and I've got some blogs and other writing I could share. Short form is, make sure the teams are measured on metrics they can't easily game and choose more than one so you can see if a metric is being gamed. For example, Jeff Sutherland recommends Cycle Time, Escaped Defects and Team Happiness Metric.

The second 50% of your review is based on developmental, learning or growth based goals. Learning a new language, learning a new process, speaking at a conference, and so on. The key here is the individual goals are about making them a better employee, not if they shipped 1000 lines of code.

The two scores are put together to form your total review.

The key to this is it prevents teams from falling into conflict over who gets credit for work done. The whole team is measured equally. It also helps with self-organization as it is in the team's best interest to help the team member who is falling behind.