While metrics and data are valuable for tracking the progress of a development team, or any organization, numbers are almost always the wrong thing to anchor the primary focus on, according to David Laribee, CEO and cofounder of digital transformation consultancy Nerd/Noir. Instead, the focus should be on the overarching objective, Laribee says.
“I start by asking, ‘What do we want to have to happen and what will happen if we are successful? From there we can back up and figure out what metrics point in that way,” he says.
Part of the reason metrics can steal focus for the end objective is that people find solace in data, according to Laribee, who adds: “There is a comfort in the quantitative, but there is a false sense of security that can come with swaddling yourself in data.”
Further, development is hard to measure and the process can seem like a bit of a black box for non-technical leaders. This can also lead to an overreliance on metrics. In these situations, the instinct is often to measure activity, but Laribee says that activity alone doesn’t reveal if the desired results are being achieved or if a team is working up to its full potential.
3 pitfalls of metrics chasing
Laribee lays out the following three pitfalls and fallacies that revolve around development teams focusing too heavily on metrics instead of outcomes. While Nerd/Noir works on improving the outcomes of development teams, the following challenges can befall any team that monitors progress using data pools.
1. Juking the stats: In the pursuit of metrics-based goals, teams might start working on ways to manipulate the data or otherwise game the system to unlock better results, Laribee cautions. This type of behavior can also pull the team’s concentration from the overarching goal.
“If I know velocity is what I’m being measured on, I’m going to kind of juke that stat, so to speak. I’m going to muck with it and maybe do some creative accounting,” Laribee says.
2. No one metric rules them all: Placing too much focus on a single metric can also leave teams on perilous footing and stifle innovation.
“If we’re investing too much in a single metric, we’re really losing the nuance of where improvement needs to happen in different teams, especially in very large organizations,” he says.
Further, goals will vary from team to team and the metrics that matter to one team might not be all that important to another.
3. Stagnant goals: Laribee points out that metrics are not static and should vary based on a team’s collective ability and the outcomes they are trying to achieve. In addition, teams that fixate on a single metric could become resistant to change, failing to adapt and evolve as a result.
He explains that consistent performance in certain metrics may indicate that a team is outgrowing those objectives and more ambitious targets should be set.
“The idea that you’re going to have one set of metrics that are going to live with you for the rest of your life is the biggest fallacy that we are challenging. It’s much more nuanced than that,” Laribee says.
Giving up the chase
When it becomes clear that a team is too focused on metrics, Laribee recommends a two-pronged remedy:
Realign the team with goals: Leadership should communicate the purpose of the team’s goals and emphasize how the work supports the larger objective. When leaders can effectively explain the “why” behind an assignment, it can help developers better understand how a technical task, such as building database tables, fits into and supports the organization’s larger purpose.
Metrics training: Team members as well as leadership should be educated on the importance of metrics. This training should include details on what it means when metrics fluctuate as well as how metrics are and aren’t being used.
“That kind of education is shockingly absent from the groups that we’re working with,” Laribee says. “That kind of coaching and training is really important in your development plan and how you develop leadership and contributors.”