Ask HN: New Manager, how to measure developer performance? | Hacker News Reader

Ask HN: New Manager, how to measure developer performance?

8 pointsNewManager20214 comments

Background: Due to some wild circumstances, I have gone from being a senior developer to the team lead of eight developers in another department with zero hand over or training. This is my first time as a manager, I have never worked with any of the team and have only briefly meet them before. I have talked to the business and the team has a concrete goal to develop and deliver a software project in six months. There is also a big push to raise the quality of the work done, under the last manger features were late, buggy and had a lot of downtime which has been impacting revenue.

Question: In six months time, I will need to deliver a performance review for each member of the team. How do I define the goals for each developer and measure their performance against it? The core goals being features on time, less bugs and a lot less downtime in production.

View on HN

9 out of 10 times it's not the developers failing to deliver, but the management failing to provide a good plan and making bad decisions. I suggest that if you're only given the nebulous goals of better quality and less downtime, you're going to fail. You need specific goals, like in terms of specific features, that the business wants, then you figure out a plan to achieve those features based on your tech stack and code base within maybe 4 months, and if there are too many features to do that, you push back.

That 4 months of features will give you 6 months of work. Then, just ensure you're testing things in a staging env and that you have good ci so that you don't get production downtime.

Honestly, though, if they haven't thought of this stuff before and haven't talked to you about this, then it sounds like they're just putting you in s position to fail. You shouldn't have to come to hacker news to get help, and when a department is in dire straights you don't put a developer with no management experience in place, you either pay double to hire an awesome manager right away, or a vp or department head should go down and take over for a while to get it into shape.

You should look for new jobs over the next 6 months maybe, too. Just in case.

https://blog.pragmaticengineer.com/performance-reviews-for-s...

The above is a great post that should get you 90% there. Having a good career ladder in place makes performance discussions relatively easy and plays into the larger picture of setting expectations and giving feedback. If your overall organization doesn't have a career ladder, you can call it an expectations framework within your team. At the end of the day, you just want to be able to articulate what the expectations of each level is and have discussions around that.

The goals you've listed work well. For instance, in your expectations, you could have a "Quality" section that outlines all engineers must have tests for their code. The hard part here is thinking through the reaction your expectations will have. After all, any metric that can be gamed, will be gamed. You also want to make sure that you're creating expectations on things engineers can actually control. This will be the single best thing you do to communicate what is important to the team.

As for individual performance metrics, I've never found anything that made me feel good about it and I've since stopped trying to create any type of measurement. Individually, I look at meeting/exceeding expectations and leave it there.

One more thought. As you're new to the team, I'd involve the team in the conversations around raising quality. Their buy-in will be important.

I would try to focus on really meeting them, have your 1:1s, ask them what the issues are with the product in their opinion, where they would focus efforts in the product, how they feel at the job, what are their aspirations and etc.

After a month or two in the job you will likely identify a couple of things that do not feel right, ask them about it and how they feel about it. Use a mix of your gut feeling and data.

> The core goals being features on time, less bugs and a lot less downtime in production.

This seems like a great way to start the conversation with the team members, make it clear that this is your expectation and what is getting in the way from each person PoV.

Check out this recent paper by Dr Forsgren et al. on measuring developer productivity: https://queue.acm.org/detail.cfm?id=3454124

Multi-dimensional analysis is key to building up a truer picture -- and can give you some ideas of what you can set as goals.

Reply on news.ycombinator.com