Whether you're an engineering manager focusing DORA/SPACE, an individual contributor tasked with watching Datadog, Splunk or Sentry (and PMs, I know you've got Pendo, don't try to lie), chances are if you're involved in the building of software you're all but drowning in analytics. We analyze how long it takes an engineer to write code, how long it takes for DevOps to get in production, and how many times each user clicks each button.  

And it always makes sense in the moment to be tracking all of those ... Until you have dozens of engineers working with different DevOps teams and millions of users, and suddenly your data lake is flooded and the only action you have time for is checking, "number goes up?"

I want to take a step back, breathe, and talk about what analytics are actually useful for driving growth, both of your team and your product. We'll discuss the importance of engineering productivity metrics without focusing on them entirely, and you'll hear me drop lots of references to Campbell's Law. Hopefully you'll come away with a framework for deciding what analytics are important, as well as the language and knowledge to persuade others on your team (up and down the managerial stack).