Metrics aren't about measuring productivity or grading someone.What has to happen is you have to ask yourself "If this team is not as productive, Team A is not as productive as team B... what's in Team A's way? What can we do to help them? Are they having trouble writing tests? Are they not getting the regression paths that they pass as they need to through the test suite? Are they having an ID that they're using that doesn't integrate well with our backend systems? Is there something else there that's slowing them as they go through this cycle time to being productive?"

Don't use metrics for the wrong reason

Jerry Li: Are the managers accountable for improving metrics to create a better environment for developers to be productive?Allan Leinwand: They're not responsible for improving their metrics. There's no judging of managers based upon the metrics. There's judging a manager at based upon the product they produce or the infrastructure they're rolling out or in the developer productivity team, the tools that are produced to help that.

Team metrics don't grade the manager

So I think that some of the important metrics that we look at to get to the right answer are again, things along the lines of how quickly can a developer get an environment? How quickly can they get tests written? How quickly can they get a build deployed? How quickly can they get that code merged? How quickly can they get things out the door?

Engineering metric examples

"I generally say developers want to do three things... They want to solve hard problems at scale. They want to see that hard problem when they solve it... get put to use! The third thing that I think, honestly, is they just don't want to work with jerks.﻿I think if you master those three things then you end up with a very happy and productive development team.”

I'll give, I'll give you an example. Here at Slack, we had a... pattern over the past year where people were not having enough time to sort of spend time to actually doing coding. And when we actually went back and surveyed our developers, they were saying they didn't have enough time to do "deep thinking."So we actually devised something we call "Maker Time" here at Slack. This is an example of what we did. And we said I think it's Tuesday, Wednesday, Thursday, Friday for three hours in the morning for all individual contributors, no meetings. Full stop. Like schedule time around that.

Maker Time

If you're measuring and managing engineering teams by metrics, I think you're missing the point. Metrics can give you information about the car you're driving, but they don't drive the car.

Allan Leinwand, SVP of Engineering @ Slack shares his core philosophy & approach to creating developer productivity AND happiness! You’ll learn how Allan combines what developers want most + metrics & analysis of the dev pipeline to optimize productivity. Allan covers how to translate those principles to remote/hybrid work and how to tell (and what to do) if your dev teams are unhappy.

ALLAN LEINWAND

Similar ideas

A junior developer needs a mentor.

Applying the First Principles Thinking

Turn The Ship Into The Storm