As engineering managers, you are no stranger to metrics. From lines of code to uptime, the software development industry is almost too obsessed with numbers. But when it comes to measuring the performance of an engineering team, engineering managers often get stuck.<\/p>\n
There are two types of people, those that don't believe in quantitive metrics and those who do. I belong to the second group. This does not mean I don't look at qualitative feedback but quantitive metrics can tell us a lot of stories and paint a great picture if you know what to measure in the first place.<\/p>\n
In this article, I will talk about how you could think about what metrics to measure, based on the unique situation of your team and what steps to take in not only measuring but improving the performance of your engineering team. Because the ultimate reason why you want to measure it in the first place is so you could improve on it. Just like the saying goes, you can't improve what you don't measure.<\/p>\n
There are two types of metrics you should look at when it comes to measuring the success of a software engineering team: qualitative metrics<\/strong> and quantitive metrics<\/strong>.<\/p>\n The first type of metrics is qualitative metrics. Usually, this can be achieved by talking to people\u200a-\u200aemployees and customers.<\/p>\n Many software companies use NPS (Net Promoter Score) to measure customer satisfaction. Looking at customer-driven metrics ensures your software engineering team is delivering value to business and customers.<\/p>\n Under qualitative metrics, you may also want to get 360\u00b0 feedback on individual team members to evaluate their performance.<\/p>\n When measuring the performance of a team qualitatively, it's important to pay attention to low performers within the team. Like the saying goes, one rotten apple spoils the whole barrel. Although it may just be one single person in a team of ten, that one person can have a significant impact on the performance and morale of the entire team if they are low performing. Being able to identify low-performing engineers as early as possible comes from experience.<\/p>\n There are multiple reasons why they may be performing poorly. Some of them are:<\/p>\n After identifying the root cause, the software engineering manager can then come up with an appropriate plan.<\/p>\n Possible actions are:<\/p>\n You will then observe the same feedback loop and metrics to keep track of progress. If none of the above works after a period of time, it is time to consider letting them go.<\/p>\n The most rewarding part about being a manager (at least for me) is to play a part in people's career growth through coaching and empowering them. I've found that the best way to keep people motivated and engaged at work is to give them training and professional development and stretch assignments.<\/p>\n However, it's not all fun and games. The difficulty of the job as a manager involves managing people when they're not performing up to the expectation. Continuous feedback is important to make sure that you are providing support and guidance to your people and they know where they stand.<\/p>\n Timely and actionable feedback is important and you should not be afraid to have tough conversations with them. You are not doing your job as a manager if you are sugarcoating performance or behavioural issues.<\/p>\n This is just one example of how important qualitative feedback is in identifying issues and working through them effectively.<\/p>\n The second type of metric is quantitive metrics. They can be represented numerically and obtained scientifically.<\/p>\n Examples of quantitive metrics that can be used to measure\/manage quality, delivery, and productivity in software product development are:<\/p>\n Time to\u00a0delivery Quality Uptime (reliability) Speed of\u00a0delivery Team velocityQualitative Metrics<\/h4>\n
\n
\n
Quantitive Metrics<\/h4>\n
\nCycle Time
\nLead Time<\/p>\n
\nDefect rate
\nPercentage of test coverage<\/p>\n
\nLatency
\nTime to recovery
\nIncident detection time (Mean Time To Detection)
\nIncident recovery time (Mean Time To Repair)<\/p>\n
\nAverage age of closed bugs<\/p>\n
\nNumber of releases
\nNumber of story points completed
\nRate of story completion<\/p>\n