Google’s Magic Metric | TechWell

Google’s Magic Metric

Every job has a downside—even at one of the most innovative workplaces in the tech industry. There’s a thread going around the Internet on the worst parts about working at Google.

The surprise is in the most-upvoted reply:

(A)ny improvement not based on a hard metric was flatly not a respected use of time. Usability? Number of bugs? Nobody cared. If you couldn't measure it, nobody was interested in it.

Isn’t bug count a metric? I mean, sure, we whine that not all bugs are considered equal, even using fancy terms like construct validity, but bug count is a metric, right?

Apparently not a hard metric—or at least, not hard enough to matter here. Why?

Because Google can put ads on every page and charge for every ad. That means the number of hits on the site is directly correlated to revenue.

If you fix a lot of bugs, the next question is: Did page views go up noticeably? Did revenue? If the answer is no, what does it matter?

You can only do this if you have a magic machine that matches behaviors to revenue. Even at Google, the machine isn’t perfect; the correlation just needs to be strong enough, enough of the time. This is a great mixed blessing, because the metrics tend to be extremely shortsighted.

What the Magic Metric Means for You

Most companies do not have a magic metric, so they search for something else. They settle for bug count, or percentage of coverage, or schedule conformance. These are measurements of process; they appeal to middle management because it makes evaluations—and, to some extent, project prediction—easy.

Technical people want to talk about things, which often don’t fit into easy process labels. But process metrics don’t tell you if you are making money, which is what senior management cares about. If you want to get the ears of senior management, find a way to connect the performance to money. Find your own magic metric.

It might not be the kind of thing that shows up on a dashboard, and it might take a little work. Say, for example, a register does not send the email to a new account. That’s a critical bug—but how many people register per day? What is the cost of those lost registrations, even per second? The cost of leaving that feature broken might not be directly calculable, but it can be approximated, and that certainly has more meaning than percentage of coverage according to some model.

Once more, with feeling: Executives tend to think about money, management about process, and technical staff about things. To help executives make decisions, we need to connect the things to the money.

Some companies, like Google, have magic metrics to do the connection for us. If you don’t work at Google, you might have to build it yourself … or else have a proxy measure inflicted upon you.

The choice is yours.

Up Next

About the Author

TechWell Insights To Go

(* Required fields)

Get the latest stories delivered to your inbox every month.