Hey there! I'm Nat Bennett, and you're reading Simpler Machines, a weekly newsletter about making software.
Today, some advice on how to make metrics suck less, by thinking about them the same way as the squeaky-dog voice.
You know the voice I'm talking about. The obnoxious, high-pitched, "Who's a good boy? Yes it's you, yes it's you!" voice?
If you haven't had a dog, you probably hate that voice. It sounds stupid. The person using it sounds stupid. You hear the squeaky dog voice and you think, "This is not the voice of a serious person."
The thing is, the squeaky dog voice is the voice of a very serious person. Serious about making their dog understand them. So serious, that they don't care how stupid they sound to other humans.
Dogs love the squeaky dog voice. They can hear it better than the normal human pitch. They like it. Hearing it makes them feel good. To them, it means that you're friendly, and that you're happy with them. They'll learn what they do that produces it, and they'll do those things more. If you're serious about having a well-trained, well-behaved animal, you use the squeaky dog voice.
So what does this have to do with talking to executives? Simple.
Metrics are the squeaky dog voice, but for business.
If you're not a manager, you probably hate metrics. Even if you are a manager, you might dislike them. They're reductive. They're gameable. They're everything that's wrong with modern business. You see someone asking for metrics and you think, "That's not a serious person."
But executives love metrics. They can understand metrics. If you want them to listen to you, you need to learn to use metrics.
Why executives love metrics
I joke that metrics are "the only language these people understand!" And it's not because executives are stupid. It's just the nature of hierarchy.
Managers of managers, and managers of managers of managers, are overwhelmed by information. Their job is to co-ordinate an organization that vastly outnumbers them. Think about how much you read, how much you write, how many decisions you make, every day, doing your job. Then multiply that by 8, or 80, or 800. That's how much raw data is coming in that might be relevant to any decision that a particular executive might need to make on any given day.
And it's actually worse than that, because executives are also co-ordinating across time. An individual engineer's time horizon might be as short as a day. It's rarely longer than six months. Executives regularly need to consider time horizons in terms of years.
So they have to have some way of condensing and filtering all that detail. One way that they do this is with stories. But the other is metrics. Metrics are a way to condense a lot of information down into an executive-perceptible core.
By speaking in metrics – preferably with a good story attached – your voice cuts through the noise.
How to pick good metrics
Here's the thing about metrics. The people who want you to use them? The manager or director that's asking for a dashboard?
They don't care what's on that dashboard. They don't care what metrics you use. They just want to hear the squeaky dog voice.
What this means for you, my metric-hating friend, is that you can get a lot of control over how managers think about a situation by volunteering to define the metrics.
There are two steps to using metrics to
seize power exercise influence:
- Figure out what you want to happen.
- Pick some numbers that will go up if it does.
My thing is deploy speed. I want deploys to be fast and frequent. I do believe that it makes teams more effective, but I also just personally prefer working in fast feedback environments. So when I get a chance to get put in charge of the team's metrics, I always start with deploy speed itself, and then throw in deploy frequency, and if I can swing it, lead time to change.
Then, when we're deciding what the team should work on, I say, "We're going to spend some time making deploys faster so the number goes up." Everyone's happy, because the number's going to go up.
Then we do the work, deploy speed increases, and the people who asked for the numbers are happy. The number went up! And I'm happy, because something that I care about happened.
You can't use this technique to completely take over a roadmap process. You can't just substitute your preference's for the company's. But if you've got a reasonable story and you're willing to spend some time turning it into numbers, you can get a surprising amount of influence over how your team approaches its goals.
For more on this topic read "Plato's Dashobards," by Fred Herbert, where he gives an in-depth treatment of common bad metrics and how to avoid them. Also some fantastic examples from medicine of handling proxy metrics, and describing the relationship between the real thing and the proxy.
Focus on the right thing to measure, even if you can't measure it
A lot of the problems with metrics come from measuring things that are easy to measure because they're easy to measure, and then pretending that they're the right things to measure.
You're going to have to do the first part – measuring things that are easy. You don't have to pretend that they're not proxies.
Always start by figuring out what you'd report on if you could report on anything. Then figure out if you can measure it. If you can't measure it, find a proxy, but include an explanation of what it's a proxy for whenever you present it. This has the added bonus of making your number look more sophisticated.
Your proxy measure will, eventually, escape its containment and get used for something stupid. But that would happen to a stupider metric, too.
Use the phrase "leading indicator"
I don't know what it is about the phrase "leading indicator" but it is magical. If I say, "Slow upgrades cause customer turnover" people try to fight me about it. If I say, "Upgrade speed is a leading indicator of customer turnover," everyone nods sagely.
You can combine this with the "what you wish you were measuring" technique and say things like, "Now if we could measure [something that's hard to measure] it would be a leading indicator of [thing we care about]" but this is some dark wizardry and you should be cautious. People will continue to agree with you even if what you're saying is utterly fact free.
What's missing from this post? Do you have any techniques for making metrics more useful, or at least less painful?