[tytso]

Do you really work for Google? It's possible to find metrics for most things. It might be the number of times SRE's get paged. It might be reducing the amount of time SWE's need to worry about thread safety; so even code cleanup can have metrics. The trick is to think big, and to think at scale. Not how to improve things for SWE's working in one team, but many teams, if not all of Google.

This is why life is sometimes easier for the infrastructure teams; increasing disk or CPU utilization by even a fraction of a percent, when multiplied across a large number of systems, can be a big number.

Now, if your product which is measured as having a small number of users, and worse, that number is decreasing over time (which was the case with Google Reader, as has been publicly disclosed), the problem is not that you don't have metrics, but the metrics aren't telling you want might have necessarily wanted to hear. Down and to the right; that's a different story...

[fkdjs]

Yup, and it's used by everyone, especially execs, and acts as a swiss army knife. Yet the team is mostly leaving in droves because although it's quite useful, it isn't correctly measured and it doesn't bring home the bacon. So the project is sometimes wrapped up and repackaged by a customer-facing team to steal the glory and get bonuses, or teams put it under them and scale back perks/force us to use them vs other teams who want us to cater to them. So silo'ing, everyone wants the goods. I've contributed lots of infrastructure code that customer-facing teams use, gets who gets the large bonuses. Proposals to fix this and measure impact have been brought up and slapped down by managers. I'm leaving the group after wrapping up some stuff. Fortunately I have high perf scores. People make warm comments about how useful the project is, but at the end of the day, it's never going to give me a $200k bonus, so it goes in one ear, out the other.