Engineering managers know that analytics – and especially metrics – are vital tools to monitor the pulse of their developer teams and to assess how output or processes can be made better. Unfortunately, more often than not, those metrics don’t motivate anyone — at least not without connecting them to a bigger picture.
About the author
Rob Zuber is CTO at CircleCI.
Many managers, in an effort to help their teams work more effectively, direct their attention towards operational or execution metrics as the problem to be solved. Unfortunately, these metrics are generally a trailing indicator and treating the metric as the goal is fraught. Developers become suspicious about their use, and lose sight of the deeper value that the right metrics can unlock for them, their team, and their work.
Why developers should care about metrics
To state the obvious, managers care about metrics because that is part of their role. Conversely, developers can be suspicious that metrics are only being used to evaluate their individual performance, and that they’re not always an accurate representation of their work they feel they do. For the developer mindset sometimes the answer is binary: Did I get the job done, or not?
With metrics in software delivery a lot of developers think of execution metrics like throughput, delivery, and number of deploys. Managers will find though that these types of metrics don’t motivate anyone in and of themselves. What’s more impactful is paying attention to how the work engineers do every day is connected to the mission of the company they work for and the customers they serve. By adding a direct link to meaning, the ecosystem can make a connection between the job, the impact, and who the job impacts. It all comes around in a more meaningful circle of relationships.
How engineering teams can identify the right metrics to measure
Managers want their developers to be motivated, to improve and to have the tools, including metrics, so they are able to own that improvement. There’s a clear process to start this journey with.
Firstly, managers should secure essential clarity on the goals the team is trying to accomplish together, and as part of the larger organisation. Secondly, they should figure out how they’re executing those goals right now. Then, for the third step, analyse and clearly lay out what gets in the way of success.
At the leadership level, managers and executives are focused on business outcomes. Many technology companies have moved to the Objectives and Key Results (OKRs) framework to clearly communicate business goals across the organisation — and how everybody’s actions should map onto that. So, whatever the current objective, like driving down costs, increasing engagement, or trying to increase average revenue per customer, this is the business-level view.
Developers must see how their team’s outcomes should support the vision and strategy of the company and understand them without needing to track them individually. In fact, not every engineer needs insight into operational metrics, such as if they are meeting all their deliverables on time. Rather, managers need them to understand what the company is trying to achieve. At the end of the day, what is the outcome they are trying to deliver to customers and for the business overall?
If a company’s engineers have clarity on the overall mission and vision, they understand how their work impacts the big picture. A team will be more motivated (Does it feel like we have too many incidents, issues, and escalations from customers? Are we far off on our estimates?) to get better and better at delivering because they can see the direct impact. Individual contributors will begin to use metrics to improve their job, solve their problems and become better teammates.
Agile methodologies are all about continuous improvement — particularly the retrospectives. No matter where the team is on the spectrum of hitting its goals, managers should be continually reflecting on their progress and asking themselves how they can be better.
Harness metrics to great teamwork
Executives should introduce high-level goals and ensure that the whole business can see where the company is aiming to go, how it will differentiate in the market and all the things that are vital to a business strategy. At a level down, managers communicate how teams should think about those goals from a product and engineering perspective, yet still position them within an overall business context. Managers cannot be mere conduits. Framing the work of the team against a backdrop of broader business goals allows engineers to bring their skills and creativity to those business problems.
Building software is not as numerically driven as many would like it to be. It’s often seen as in a constant state of design. On the other hand, it’s important to recognize that many of the novel capabilities we create involve a different assembly of well-known components. That creates the opportunity to see if we are improving at solving similar problems.
And in a world of agile development and continuous deployment, companies have much faster and richer feedback from customers to see the impact they’re having on them. That gets everyone excited.
Managers need to ensure that their team has clarity on their business goals and feel motivated to deliver because they’re excited about what they’re doing. Then they can help them understand how to use metrics to diagnose any issues. They shouldn’t assume that if you just hit execution metrics, that their business results will follow.
If companies start with the reason and they end with the numbers, they will know they’re on the right track. Managers will know they’re getting there because they’ll see the numbers moving, their team will be excited by that, and they’ll be motivated to do even better.
