Register or log in to access this video
Are you wasting time analyzing the wrong data?
As a software engineering leader, metrics can be both your best friend or your worst enemy, depending on how you use them. While they might help you solve problems and identify ways to maximise productivity, they could also lead to compounding of the problem and resentment in the team. Based on insights from 4 professionals: Cat Swetel of Agile Alliance, James McGill of Code Climate, Dalia Havens of Replicated, and Juan Pablo (Engineering Leader), you’ll be able to develop a better understanding about the world of metrics.
How are metrics used?
James says that he primarily prefers to use metrics because as a human, he might tend to miss things. However, data and metrics can enable him to spot issues that he would’ve otherwise overlooked, and solve these problems before they become major issues. On the other hand, Cat uses metrics to validate the work done by knowledge workers, whereas Dalia thinks of metrics as useful problem-solving tools.
She described them as a means of debugging organisational problems, and she’s refined her metrics and data through the course of her work with several similar organisations. At the same time, Juan thinks that metrics are a useful tool in understanding the efficacy of solutions, and ensuring that productivity levels can be maintained even as the organisational scales up.
What are some good and bad reasons for using metrics?
For an engineering organisation, good reasons for using metrics would include analysing problems or patterns to see abnormalities, or for identifying concrete targeted solutions instead of abstract ideas. They help ensure that the team’s efforts are being focussed in the right direction towards the achievement of organisational goals.
At the same time, there are also a variety of bad reasons for using metrics, such as when they are used in a punitive manner instead of as a problem-solving tool. Also, leaders might sometimes provide arbitrary metric-based targets to “game the metrics” and show good results, which hampers productivity and leads to organizational problems in the long run.
How do you design metrics and give access to employees?
The best way to design metrics is to temper the numerical analysis with the fundamental human edge to arrive at a conclusion that incorporates the best of both worlds. It is also crucial to have the right objectives while using metrics: you’re not trying to game the numbers, rather improve processes to streamline inefficiencies. In addition to this, employees should clearly know how these metrics are calculated and where the raw data comes from.
Providing access to employees and increasing visibility will enable the team to collaboratively come up with solutions to problems before they manifest themselves. Another crucial part of the metrics design process that Juan pointed out was to use common sense. As obvious as it may sound, many managers ignore common sense completely in their quest for the highest numerical efficiency, which renders the metrics useless.
How do you report metrics data?
Once you have designed the right metrics and given your employees access, the next step is to think about how you would report this data. Cat and Juan both agree on the fact that often, individual metrics shifting by a few points does not make a difference, but the correlation between different metrics is something that needs to be monitored.
They also stress on their observation that leaders are usually worried about the individual data points, which is pointless. What they should really be looking at is the data trends and whether these trends are in line with what the organisation is trying to achieve.
Therefore, the use of metrics in an organisation, while extremely useful, is also a bit tricky to handle and requires a great deal of calibration. It is important for software engineering leaders to know how to formulate, design, implement, report on, and share different metrics so that they can be used to boost efficiency and create a better work environment.
