https://blog.pragmaticengineer.com/performance-reviews-for-software-engineers/ https://blog.pragmaticengineer.com/performance-reviews-for-s... The above is a g

https://blog.pragmaticengineer.com/performance-reviews-for-software-engineers/ 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.