Mean time to repair

How long does this equipment last? And with clean energy and EV chargers, that data isn't necessarily as transparent.

And then the other metric, you know, MTTR or mean time to repair, like how quickly does it take us to repair those failures, right? And that's an internal self-look on how do we handle understanding our downtime.

So if I have downtime that I accredit to, you know, let's say wiring issues or fuses, right? If that wiring and fuses are understood and it takes me two weeks to respond to that downtime, how do I quantify that and start to improve my mean time to repair? And that comes down to, do I have the parts? Do I have the work order system? Do I have the scheduling or bundling of work? And do I have technicians that can complete the work? And am I closing that work out sufficiently? So when I look at those two metrics, right, we can start to move the needle on, are we actually looking at reliability from a, you know, how can we prevent it? What do we know about our equipment? And what do we know about our response to that equipment?

Yeah, I've seen that.

And there's a whole host of those.

You've got MTTR and MTTD as the key metrics for the second era.

Blast radius is the third, is the additional metric that we need to introduce at the board level.

So our mediative approach is we're going to have a blast radius score and have confidence that if something happens, it's only going to travel so far.

I met Shai and he had already built a tool that could write and optimize logging code.

And he was talking about reducing MTTR and the amount of time that his team spend on maintenance and how he wanted to automate a lot of that away so that his team could focus on what was more important, building new features and innovation.

while maintaining really great software and having a great customer impact from that software.

So he'll always say that the customers and the team are more important than the software, which I love to hear that coming from a CTO especially.

But Shai and I really bonded over reducing MTTR because in my experience leading the customer side of the house, I've often had to go beg for my engineering partners and projectors product partners to help me resolve issues faster, especially for our most important and our biggest customers or customers that are currently in a pilot or all of those kind of metrics that you know in an offhanded way when you're on the customer side of the house, but that engineering really doesn't have visibility into.

And so we started Strudel with all of this in mind.

And what we often talk about is the single pane of glass for this data.

Yeah.

You look at MTTR mean time to repair.

When you catch a failure early, you don't have to spend three days cutting off a fused, melted bearing.

You just spend three hours doing a clean swap.

I mean, we should be able to, if we're making progress, we should be able to have subtite- some type of numbers to support it.

The numbers could be we're improving MTTR.

Oh, that's awesome.

We have reduced our security vulnerabilities.

That's what DORA has always been about, measurements.

What should we measure now? Here's what they're saying.

Before turning on AI, you need to be measuring platform quality, CI/CD speed, code review SLAs, incident MTTRs, and deployment frequency.

Okay, baseline everything.

These are things we should be measuring anyway.