I was part of a group at Google called the Code Health Intergroup. People would come to us because we were the code quality people and they would say, how do you measure it? And mostly we would tell them, don't, don't do that. It sort of ends up making you narrowly focused on some of the wrong things. A lot of engineering issues ultimately stem from some factor of code health or code quality in the long term. That's what I eventually came to, and all of this sounds very simple. The thing that I'm about to tell you was revelatory, like a revelation to me and every other person in the room to whom I said it to the first
Max Kanat-Alexander, the Tech Lead for the Developer Productivity and Insights Team at LinkedIn, shares an inside look at LinkedIn’s metrics platform and how teams across the organization use it.
Discussion points:
- (1:31) Why Max shares how his team is measuring productivity
- (3:20) Why some teams use metrics and some don’t
- (6:03) The types of metrics Max’s team focuses on
- (12:59) The role of TPMs
- (17:05) How Max would measure productivity if he weren’t at LinkedIn
- (25:04) Surprises in how teams are using metrics at LinkedIn
- (31:27) The tooling required to enable metrics for teams to use
- (36:41) Qualitative versus quantitative metrics
- (40:39) Measuring code quality at Google
- (46:16) Whether a centralized team should own measurement
Mentions and links:
Connect with Max on LinkedIn or Twitter
Read the article, Measuring Developer Productivity and Happiness at LinkedIn
Listen to the first interview with Max and his colleague Or Michael Berlowitz: Episode 23
Abi’s blog post on the Three-Bucket Framework for Engineering Metrics