Jennifer M. Hansen

Hi, everyone. I don't know how I can top that. I can't dance, and I'll have to practice.

So, hi, I am Jennifer. I'm here to talk about the Triple M for DevOps. Luckily, it's not the Triple M for murder, so let's go.

So what's the Triple M? It's meaningful momentum metrics.

Meaningful because it needs to matter, aligned to your org's vision. And it needs to have and be able to build momentum.

So what is momentum? Well, it's mass with motion and, more importantly, forward motion. Some of the things that we need to consider is the amount of momentum we want really depends on how much stuff is moving and how fast it's moving.

So let's think about our metrics. Define them well, target the outcomes we want, and build the momentum we need.

Yes, it's not the eight ball in the pocket that you want, but the snowball effect. That's the momentum you want to drive. Not for the one developer, but for that community of developers.

So, like all of you, I too care deeply about the developer experience. And I care about it because the metrics give me the insights I need to make them happy. Happy developers are productive developers. They love to exercise their craft. They love to work on the stuff that matters to them.

And the metrics give us great insights. Insights into where they are impeded, where is that momentum blocked, how can we keep them in the state of flow, what are the things that are really there. The platform's not performing. How can they do the job they're being asked to do?

So look through the lens of the developer.

Now that you've figured out what you need to do, how you do it matters. And ultimately, that impacts your business goals. So all of you there in leadership, I hope you're listening: the how matters.

For example, I would love for her to have that 6% optimization, but did I solve for it accurately? Did I give her the tools that she really needed and something that was useful for her?

So let's not do that. Let's be thoughtful about our frameworks, our languages, our choices, and our tools.

A common lexicon is essential. We need to always focus on what it means. How are we measuring it? And be transparent and open. Build trust.

For example, you may think it's 24 inches. Someone else may think it's two feet. We often want the same. Management and engineers want the same outcome. We need to get to the same lexicon.

The good news is this, that all of you around here know we have a rich DevOps community and people that care. We've got Accelerate. We've got DORA. We've got SPACE. And we know we need to make our investments.

There is a lot here that we can learn from. We are not starting from scratch.

And there's this new thing called production access debt. That's an interesting one I want to talk a little on.

So all of you know DORA and have heard a lot about it. I'm not going to go through this, but we need to be thoughtful on how we apply it, how we define it, what's right for our org. How do we want to benchmark it?

SPACE. I love Nicole's callout. It is multifaceted. Do not align on one dimension and create metrics that could be misleading. Focus on what outcomes we want and look at it from multiple perspectives.

Production access debt. We don't like debt. And if we start with zero debt and no production access, and apply an approach that makes us think about why are our developers there, what makes them want to go and work in production, how mature are our practices, the five whys will get you there. You'll know exactly what to focus on.

So here we go. We are back to the metrics soup, and I promised you the Triple M. So here's how I like to think about it. A lot of different things. Take your choices, figure out what you need and why, and then ultimately assess the impacts that you have on your teams.

And I'll speed this up. It's all about that momentum, and how fast can I go with the clicker?

So think about it. Focus on ensuring that you're doing the things that our developers do repeatedly and make that easy.