Many managers use engineering metrics to set goals. They measure the product delivery process and then use these numbers to set OKRs, attach to a pay raise or promotion, or micromanage. All the ways lead to pressure for achieving a specific number.
I’ve worked in teams in which managers would make leaderboards and control every individual’s output. It didn’t solve the problem, though. Micromanaging only increases illusory productivity, not the performance itself.
At the cultural level, it changes how the team dynamic works. Individualism increases and the team starts to make bad engineering decisions. The focus becomes to be at the top of the leaderboard, not delivering an excellent product.
There are other ways to use metrics. They serve multiple purposes, and managers can use them on different occasions. In this article, I listed three better ways to use metrics within engineering teams.
Metrics to motivate the team
Nobody likes to have their work wasted because of misalignments. Engineers want to work on what’s important and relevant. Add challenges to the equation, and engineers will have fun doing their jobs.
In this sense, managers need to communicate what’s most important clearly. If the team understands the plan, it is easier for them to see how they fit.
Some kinds of work are fast, and the team stays motivated from the beginning to the end. However, when an activity takes too much time, the team may lack the feeling of achievement. When it happens, morale and motivation tend to drop. Managers can avoid it by establishing smaller, tangible, and measurable milestones in the long run.
If a team has 30 technical debts that need to be addressed, managers can break it into a doable plan. It can be fixing one technical debt by a week or fixing ten up to the end of the quarter. The tactics don’t matter.
The crucial thing here is to enable the team to sense progress. Every week the leader can discuss the progress. In this case, metrics are not micromanaging anyone. They’re an indicator of progress. If the improvement is not satisfactory, that’s the right moment to change the plans, not blame.
Regularly looking to a metric towards a plan brings a sense of progress and a frequent feeling of achievement. That’s great. Besides, don’t hesitate to celebrate small and big wins. Both are essential.
Metrics as indicators
Metrics don’t tell the story; the context does. Metrics are merely a quantitative view of the facts. That’s important to have in mind when measuring, especially for those metrics that managers take as productivity.
The usage of indexes differs from traditional goals. Goals are future-centric and represent where the team should be from now. Indexes, on the other hand, show the present, like an indicator.
Therefore, a better approach is using Engineering Metrics as indicators. The hardest part is to find the appropriate set of metrics to compose the index.
For example, the Lead Time for Change, which measures from commit to deployment, is an excellent index of how fast the team works. It includes many outputs — commits, pull requests, deployments — and practices — coding, testing, DevOps, Product.
When it comes to quality, the problem can be more complicated. As quality is subjective, engineering managers may diverge.
Choosing the correct set of metrics depends on many aspects, such as team maturity, the company’s strategic goals, and product positioning. It could be the number of bugs found in production or the meantime to a system to recover from failure.
There are many metrics that we could use. Collaboration, culture, quality are all abstract terms that need a measurement. Once it’s covered, tracking indexes’ evolution over time can point to real-life changes.
I recommend starting with what seems obvious, then polish it as you learn.
Experimentation and innovation
In the last years, lots of frameworks, practices, and tools came out. Some of them changed the way we develop software — Spotify Model, to cite a famous one. They usually come from big companies that have a culture of experimenting.
Not every experiment needs to be that big and successful, though. Small improvements in the system are enough for our daily activities. But how can we tell whether an experiment has worked or not? Yes, metrics.
If managers measure outcomes instead of outputs, metrics become a powerful tool for empowering engineering teams with autonomy and responsibility.
The teams themselves can look at the metrics as indicators and tell whether their initiatives are working or not. They can try new practices, change the process, and dive into innovation. The only restriction would be not changing metrics for the bad.
Growth Marketers use this dynamic in daily operations. And I believe engineering teams should benefit from it as well.
The secret of enabling innovation is an instrumented system and strategic experimentation. There must be a rationale behind each initiative. And metrics will tell how successful they are.
To make it useful, it requires a fast feedback loop. It would be costly if every experiment had to run for months to determine its success. Early feedback — looking at how metrics behave — enables changing directions when things are not going well.
In short
Metrics shouldn’t be villains. They are a vital tool for modern software development. There is no space for micromanaging anymore because it just doesn’t work.
I listed in this article three better uses for metrics than comparing individuals against their peers.
In summary, we should look for metrics as indicators. They can motivate the team, tell how the system responds to daily activities, and enable innovation through experimentation.
SourceLevel provides a set of metrics that managers can use as indicators. If you’re unsure about what to measure, apply for a Free Strategy Session with me. If you’re wondering how to implement pragmatic metrics in your team, Schedule a Demo, and I will be happy to show.
Originally published at https://sourcelevel.io on March 12, 2021.
