Tracking metrics is a waste of time

??? Tracking metrics is a waste of time

Hey there! ???? Thanks for reading. Each week I share tips and tactics that help software developers and product managers create more successful software projects. Get the newest issue of the Build It Better newsletter in your inbox by subscribing today.

As a tech lead and engineering manager I've usually been the one responsible for capturing and reporting on how successful my team's projects were.

I would spend hours every 2 weeks collecting metrics like # of story points completed, NPS score, average customer usage, time-to-deploy, and application uptime. Then I'd pull those metrics into dashboards, share them during our sprint review meeting, or share them in standing meetings with my bosses/clients.

It was a total waste of time. Why?

• No one could explain why a specific metric was important or what it really captured.
• We would keep reporting on metrics even if they were no longer relevant to our current priorities.
• We wasted lots of time adding infrastructure and processes to capture data on metrics that didn't matter.
• It was easy to choose vanity metrics and game them so that they made us look good to others.
• We used metrics as a way of comparing our product/team/company to others even though we had different goals.
• My bosses and clients had little context on what we were doing day-to-day and would use individual metrics as a stand-in for how things were going.

Over time I started to dread dealing with metrics and felt they were totally useless. It wasn't until late in my career that I released the truth about metrics:

Metrics only matter if they can help us make an informed and timely decision.

Instead of making decisions based on them, we often use metrics as a proxy for that decision and just collect and report on them without question.

What do the best software developers and product managers have in common?

They know how to make the right choices so they can ship successful software.

Right now you're reading a past issue of the?Build It Better?newsletter.

I release a NEW issue like this every Wednesday.

Join other developers and PMs from companies like Dropbox, Spotify, MongoDb, Capital One, and Automattic who read Build It Better weekly.

Subscribe today to get the latest issue first.

Using metrics to make better decisions

Metrics should:

• Provide just enough info to make you confident in your decisions. Anything more and you're wasting time.
• Be recent and relevant. The longer it's been since we captured a metric the less useful it is for our current decisions.
• Be shortlived. Once you know the result of the decision you made - stop tracking and reporting on it.
• Be easy to capture and narrowly scoped. If it's hard to get data for a metric, then you're probably focusing on making a decision that's too vague/broad.
• Never replace conversations and understanding. No metric can tell you as much as talking to people.

What about after you make that decision?

Assuming you're setting SMART goals when making decisions you might see that metric improve afterward. Even if it doesn't, you should stop tracking that metric until you have a new decision to make. That way you aren't wasting time tracking that metric for its own sake.

The next time you have to deal with metrics ask yourself:

• What's the decision I actually need to make? Is that decision narrowly focused or vague and broad?
• Who's relying on this metric to change without knowing the decisions that I need to make?
• What's the least amount of information I need to make that decision?
• How stale is the metric/data I'm relying on?
• Instead of relying on a single metric is there someone I can talk to and get feedback?

? Closing the issue

Metrics are a tool - don't use them blindly. It pays to be careful with how you use them to make decisions and when they've passed their usefulness.

Enjoy this issue?

Subscribe and get the latest issues of the Build It Better newsletter in your inbox as soon as they release every Wednesday.?