 Thank you for that introduction. It made it sound way more boring than I promised this would be. I was like, oh great, everybody loves hearing about Dorometrics. I bet they can't wait to hear this. So no, that's not what this is. This is actually meant to be more like some ways you can take some of those awesome buzzwords that everybody's telling your boss and actually give them some facts to back up why your work matters and how to both combat some of those talking points that they're giving you, but also some ways to make your work relate to some of these people's buzzwords. So that's more what this is. So let's start firstly with not my clicker working. All right, let's get to know each other. I gave a kind of similar version of this talk at API Days in London last week. And I'm really curious to see the split of the room this time. So raise your hand if you're a developer. Okay, and raise your hand if you're like a business technologist, product manager, product marketer, yeah, DevRel maybe if you're not a coder, yeah, yeah, maybe. So interesting split. So more like 80-20 this time around. Last week it was 50-50. So APIs, it makes sense, right? Business technologists are using APIs to sort of extend the value of their software in more accessible ways. You folks are here to use your tools of choice. So I think that's really interesting and I want to make sure that I'm covering this topic in a way that makes sense to you. But why the hell should you listen to me? Okay, so I used to work at Armory. Armory is a continuous deployment software solution. I used to work at Stoplight. Stoplight is a design and documentation software. They also do Stoplight Studio, open source. They were just acquired by SmartBear, so rest in peace. And now I work at Opsera. And Opsera is a unified DevOps platform that also includes a release orchestration. So I kind of have been around. And so the things that I have been around, I'll tell you about today. But the things I care about are people, processes and technology. And your boss probably cares about that middle. And you probably care about the right. But I feel like we all should care about the people. And so that's what this talk is going to help you contextualize some of their challenges that they have with some of the stuff that you're working on. But first, let's establish a baseline. And now you get to groan because we're going to talk about Dora. Now is the groaning part. I added this little link here because it's very funny. So if you ever have a chance to do this, do it. It'll make you laugh because it's really just like a self-assessment of how well your team is doing. And it's like, can you deploy multiple times per month? Oh my gosh, is that the bar? That's what's really funny to me is that's the bar right now. And so, you know, if you're taking this and you're deploying multiple times per month, you could do better is what Dora is saying. So this is what your bosses are hearing about every single day, right? This is your CTO, this is your, if you have the pleasure of having a chief digital officer, that's what they're learning about. And they're bringing it back to the development teams to increase velocity and increase stability. Why? Because that's going to accelerate your software delivery. So we're going to measure lead time for changes, how long it's going to take us to get a code to production. And we're going to measure deployment frequency because we want to know how often you guys are deploying. And we're going to know what the change failure rate because we want to know how long it takes you. That's what it's very much about the work you're doing. We want to measure it, change failure rate to know how long it's going to take to restore service. Are you feeling a lot? And is it taking a long time to recover? And for me, I think these are important. Don't get me wrong. Like Jeremy's talk, very important metrics, right? These are things that contribute to how well your software is doing, how well your teams are doing. But it's not the end all be all. And so I'm here to bring another slide to your boss is outcome based. So if your boss is like, I want you to give me metrics on all of these. I want you to give me a dashboard that shows me your lead time for changes every single day, right? You could say, sure, boss. Now give me this also, because I want to see our customer satisfied. If I'm busting my butt to put out all these changes as fast as I can to increase velocity. What are what are our customers even say about it? Right? Are they satisfied? Are they do they like the work that I'm doing? Here's some metrics that can help me in my job. Right? These are just examples, but say, hey, I need more transparency into our customers even enjoying and engaging with the deployments that we're busting our butts to do. Secondly, what about me? What's in it for me? Right? I'm busting my butt to really bring down that change failure rate. Man, I'm deploying securely. I'm deploying continuously. I'm, you know, pressing commit and then following all this tool chain, blah, blah, blah. I am burnt out. And I'm not the only one. And I want to know what my colleague feels like. And I want to know what the other team feels like that I work with. And I want to know what the customers see when they engage with us as a team. Right? And so here's some examples of outcomes you could measure. Glassdoor is a really good one. Anybody ever use Glassdoor? That's a good one for some anonymized data about how your company's feeling. Are your developers feeling that pain of trying to do these Dora things faster and faster and faster without even an expectation of understanding how it's impacting the business? And third, what do we get out of it? So not just what do I got out of it? What do my customers get out of it? What do we get out of it as a business? So if we're doing this work, are we actually creating more opportunity for revenue and investment, or is this vanity? Right? Are these vanity metrics for ourselves to say, oh, yeah, we improved our change failure rate by 0.5%. OK. Am I making more money from this? Is I am I going to have a job next year? Right? I think that's that's a really big thing for us all to push for to relate these outcomes back to the work we're doing. So pipeline is not the pipeline you're thinking of. Pipeline is revenue pipeline. Right? Tell me, if I make this change that is so important to this business, how is it going to contribute to the sales that we hope to make? Is it bringing more investment opportunities? Right? If we're really high velocity, really high stability, am I going to get a series B funding? And partnerships. If we're showing how cool we're doing, is it going to provide more opportunities to partner with other people doing other cool things? So I think the slide is probably your number one takeaway from this talk is like, hey, yeah, I can I can create the best, most stable, highest velocity, most secure pipeline in the entire galaxy. Tell me what the business sees from this work that I'm doing, because I want to know that we can all work together to make these outcomes happen. All right, so now cool. How do how do we do this? So people process and technology is my mantra here. And so you're going to see some key capabilities. These are a blend of key capabilities driven from the Dora assessment team themselves, from the Accelerate State of Software report. You know, key capabilities that you'll see commonly, but also blended with a more humanistic approach. So those outcomes we were talking about earlier that very much depend on humans that you'll see those reflected here as well. So foster a culture of continuous improvement. So I think that's important for your teams, right? Is hey, if we want to crush Dora metrics, not just to do it, not just to crush Dora metrics and show my boss that I can, but to do it because we want to show improvement meaningfully. And our teams care about that. Focus on team outcomes, not developer productivity. So I don't know how many of you folks have been on LinkedIn for the past couple weeks, but McKinsey's in some hot water, I would say, for publishing a really tone-deaf article about developer productivity. If you haven't read it, do yourself a favor and read it just so you know. You got to know your opposition, you know, know your enemy. Isn't that one of the top tenets of war? Know your enemy. These highly, highly paid, you know, huge top five firms are giving advice based on your individual productivity, but your individual productivity does not a business outcome make, right? So you need to be able to focus on your teams. What's your charter, right? What are you here to do? And then you'll be able to show how productive your team actually is because your individuality is important to you, but it's not important to the business. So this other one here, I have a slide that I'm really excited about to show you, Empower Developers' Tools of Choice, because right now in this economic uncertainty, this time we're all hearing, do more with less or whatever your buzzwords you're hearing, people are cutting down on tools. They're like chopping tools, right? This is inefficient. This is inefficient. We're at the open source summit. You all are using the tools you want to use, right? We need to advocate for that. It's not a cost center, and I'll show you a slide why it's not a cost center, why it's actually important for you to do your jobs. And then high collaboration and communication. So teams with high collaboration and communication are shown to be more productive and effective. That's it. Like you put a status on your Slack that said, I'm doing this, this, and this today. I accomplished this, this, and this yesterday. That counts as high collaboration. The bar is very low, people. I'm not kidding. When I said the bar was at the floor, it is. That counts as high collaboration and communication. So here's that slide. When teams decide which tools they use, it contributes to software delivery performance and in turn to organizational performance. High-performing teams and high-performing organizations enable tool of choice. Not make slashes and cuts wherever possible in the name of efficiency. That is a myth. It doesn't help. In fact, it does the opposite of help. So I love this slide because I'm very much, we need to support our tools of choice. All right, I'm going to wait for him to take a picture because I want him to do that. Thank you, all right. OK, processes. We did people, now processes. What key capabilities do you need to be high-performing? Continuous integration and continuous delivery, that's why we're here. Need I say more? That constitutes high-performing. Automation and infrastructure as code, great. We just had a really great infrastructure as code for secure supply chain talk. Hope you guys all listened because it was really great. Integrated testing and security, again. This is another one that harkens back to Tecton, that talk was really great about integrating your testing through every part of the tool chain. Jeremy also mentioned this. It's really, really important. And a culture of immediate feedback. So not just feedback from customers, feedback from each other, feedback from the business. The longer it takes you to process feedback, the less impactful your changes will be. You need to be able to do this as quickly and as high velocity to get feedback as they expect you to be quickly pushing changes to production. Teams that reported, oh, this one's really funny. This makes me laugh a lot. Teams that reported no approval process or used peer review only, achieved higher software delivery performance than teams that required approval by an external body. They achieved lower performance. Okay, this one makes me laugh a lot because you're gonna hear, oh, we need an approval board, oh, we need, you can't get this changed to production until eight people have seen it and signed off on it. It's gonna increase our stability and our code quality. That's false. That will not do that. In fact, it will slow you way down. So what do you do instead? Lightweight change approval process based on automation, peer review, very quick, easy, integrated with your workflow, okay? Don't waste time battling with the people who are gonna keep your code from production. And advocate for yourselves to give each other the peer review process that you deserve. Technology, great. Automated continuous deployment and release orchestration. So you saw a little graph in Jeremy's talk, the difference between continuous delivery and continuous deployment is very much just the difference between a check mark and an automation, right? Is a person standing there giving an approval or is your code quality enough to automatically get deployed to production? So teams who are able to do that are high performing. Unified insights. So I just said tool of choice is the most important thing for all of you to have good outcomes, not burnout, feel like you're contributing in the way that you need to be able to. But the business is gonna say, I have no visibility into all these damn tools that you're all using. I don't know what they're doing. I don't know how you're using them. I don't know how they're improving the business at all. There are now tools in place across the market that allow you to plug into your tool of choice ecosystem and display Dora metrics. As well as other outcomes across your tools. I won't say which one might be a good choice for you that I now work at, but I'll just mention that. And then platform engineering management and tool chains, like an idea of platform management, right? Platform engineering. Your teams matter, their velocity matters, but be thinking a little bit wider, right? Help your teams see wider than your individual mandate every single day. How does this contribute to the business? How does this contribute to our platform at large? Doesn't mean you have to be a platform engineer. It just means you have to have that in your brain when your teams are pushing to production. And then treat APIs as products, not just technology. So I just came from API days and that's one of the major themes of that entire program is I could make an API of this or this API could be the way we extend the value of the software that we're creating and it should be treated as a first class citizen and part of our platform engineering program. Okay, here's another little quick slide that shows you the difference between continuous delivery and continuous deployment. It's just an easy one, you know, basic. High performing teams can deploy to production on demand throughout the software delivery lifecycle. So if you can hit commit and you can deploy to production without anybody standing in your way, you're considered a high performer. The bar is very low. All right, so I wanna give you a quick case study about how all of this works in practice and how these both delivery-based measurements and outcomes-based measurements have joined to help this one particular company. So Tesoro is a stealth fintech company building the plane as they're trying to fly it. They have about 50 developers. They have a lot riding on their launch, right? This is fintech, so what they're trying to do is enable huge velocity of payment at scale, microtransactional payments at scale across the world. Huge, huge, right? That's difficult to put into perspective but what are they trying to do? They are able to get their lead time for changes down to eight minutes with 50 developers building the plane as they're flying it. So this is their baseline. This is their benchmark. They say, we can't go over eight minutes. Their change failure rate is 4.5%. Their deployment frequency is four deployments per day on average, which is not the worst, right? I know people who are deploying 10 times per day, 20 times per day, four deployments per day is pretty good. And you know what that allows them to be according to Dora metrics? High performing, right? Bar's pretty low, but it's great. It shows that if they can average around four deployments per day, you know, every few hours they're pushing a deployment, teams feeling good, it's continuous, they don't have to worry about whether the deployment will go through or not, it's been tested, stable. And then they can go home. They have an eight hour work day. And their mean time to recovery is under two minutes. So they built from the ground up a continuous deployment culture to help them smash these metrics so that when they come out of stealth and they're processing hundreds of thousands of dollars of transactions per minute, they're not seeing down times at all. That's their goal. Their goal is like, if I have more than two minutes of downtime, I'm costing my company $200,000. So that's their goal. And it seems to be working. They're considering high performing internal and external NPS scores. These developers are happy, they're excited. This launch is about to gain a lot of attention. I'm really excited that this is like the blueprint for how they want their business to operate. And so I hope when they come out of stealth that it is a success because this really shows how all these things can work together and create a culture where people are excited to work there and enabled to work there. So here's another case study. It's quick about your developer tool of choice, right? I'm an advocate for that. I think we're all advocates for that in this room. If we're here at the open source summit, we all want to use the tools we want to use. It absolutely leads to more collaboration that are satisfaction and agility. This is a non-profit healthcare. I'm not allowed to say what, but let's just say it's a good one. And then they were able to create a pipeline in 30 minutes versus two hours. So if you're at all familiar with the healthcare industry, you may have seen previously how sometimes building a pipeline can take a day. I don't know if anybody's ever encountered that from a healthcare provider. This one was doing relatively well at 2.5 hours, but they cut it down to 30 minutes. So for them, that made them a lot more satisfied with their jobs because they perceived in their own employee surveys an 80% increase in productivity. Perception is reality. If your boss perceives an 80% improvement in productivity and you perceive an 80% improvement in productivity, guess what? Y'all are more productive, right? That's all it matters. Being able to show, yes, we've done this. We've cut down on these times. We're able to push the deployment quickly, easy, high velocity, high stability, and we feel better about it. And so do you. Here's a little quick snippet of the landscape, the core model for Dora. Highly recommend you check out the full report. They're about to publish a new one for 2023. I think it comes out in October. I'm very curious to see what exciting new things they say. So what's next? I think we all should bring back some of these things to our teams and talk about what makes me feel satisfied, what makes me feel challenged, and help our organizational leaders understand that measuring metrics is important, but measuring outcomes matters to you and you want more visibility and transparency into what those outcomes are. People, processes, and technology. So if you walked away from this, I hope that's what you think of when you think of Dora metrics. Here's some ways you can identify where you are or aren't succeeding. Can you deliver quickly, collaboratively, reliably, securely, continuously? And for your business, it depends. So everybody's gonna say it depends. What does quickly mean to you? What does collaboratively mean to you? Establishing a baseline is gonna be your best bet to be able to show a change. So start with your teams. And this is my favorite watch. Yeah, your teams are going to give you the best way to establish that baseline. So do you feel like you can use the tools you wanna use, right? Do you get to see the impact of your work? And do you get to engage in your code all the way from commit to production? And not, I don't mean watch it get rejected from by somebody. That's not what I mean. I mean, can you see your code go from commit through a testing environment, through a deployment, and give you the green light at the end of it? And if you can't, if you have no idea what that black box looks like, it's time to start advocating for that change. Because that's how you become a high-performing team. So some suggested reading. Like I said, the State of DevOps report 2022 is a good one. 2023 is a writer on the corner. Value stream management. This is from Opsera, where I work now. Really good little piece published this year. And then the ultimate guide to continuous deployment. I wrote this, so if you wanna check that out, I'll only give that one a look. And then, yeah, Accelerate, which is a book published in 2017. Hopefully they come up with a new version soon because it's a really great book and y'all should read it. And that's me. And then this, if you notice the artwork and you thought it was cute as heck, this is from Yaza Design and she is fantastic. And I highly recommend her work because it'll add a little bit of spice to otherwise really annoying corporate visual artwork that you usually see in these things. All right, thanks y'all, I appreciate it. Let your bosses know.