 All right, so I want you to close your eyes and envision a scenario that's probably relatively common. You get an alert, you get a hysterical email from a customer, the site's down, there's some issue. Have you ever stopped to think how you feel in that moment? Like is your heart beating? Are you ready to spring into action? Do you want to take a nap? Are you mad that you're scheduled to be on call right now? Are you blaming yourself? You're probably making up a story about why this is happening and who's fault it is. So usually when we talk about failures or incidents, we go from like scramble to fix it, and then we have this retrospective and we create action items and everything's going to be great in the future. Except that the story and the reasons actually starts in those moments when we're banging our head against the keyboard being like, I don't freaking know why the site is down because everything should be working, right? And so that's the hard part and that's where we really start to build resilience and find solutions that, examining that is where we find solutions that lead us to successful outcomes. So we're creating more and more complex systems, more servers, more users, services, blah, blah, and what this means is we're increasing the cost of change, but we're also increasing the likelihood and the necessity for change because all of those different components need to change, they need to interact. And failure often reveals the dependencies that we don't think about between those systems. And that's true for people too. Our cells are dying and regenerating right now. Our brains are so complex we don't understand how they work, basically. And then we're putting these complex systems into teams and organizations that interact as individuals, as teams with the outside world. You know, someone has a kid, gets divorced, whatever, and there's ramifications throughout the whole team. And basically what we do is all about increasing certainty. We create checklists, we monitor, we have automated tests. And we're doing this because we're trying really hard to be certain that everything is going to work all the time. But uncertainty never goes away. And really, we're managing uncertainty. And we do a pretty good job, comparatively, I think. And it leads to something that I don't think we give ourselves enough credit for, which is that deploying is an act of courage. We're putting something new out there. It could totally fall flat on its face. We're being responsible. And this is true of features and process and teams and going on a date or getting a hobby or a new friend, right? And you're taking a risk and you're making yourself vulnerable. And usually when we talk about those words, we talk about them as bad things. Security risk, et cetera. And obviously that's bad. But risk and vulnerability are required for innovation and change and progress and for us to move forward. And trust is the willingness to risk being vulnerable. And we actually trust a lot. We trust our operating system. We trust our tools. I trust that if I type in a URL, I'll get an HTTP response back, right? I'm clear about my expectations, the input and the output. We know it's not quite that simple. But then we create systems that monitor it and check it. We're pinging the network, et cetera. And we can do this with people too. So I manage a team now. I try to have clear job expectations. And then we review them. People rate themselves. They rate their peers. They rate their manager. Everyone knows what people's job expectations are. And so what we're doing is creating a cycle of commitment. And this term actually came out of the book Understanding Computation and Cognition, and they talk about a promise cycle. So we're clear about our expectations. And then we have someone respond and acknowledge them, right? They act it. They commit. They act to report. And then they come back, and we go through this cycle. So the reason that I'm talking about this is that trust is one of the biggest casualties of failure. It's not always the cause, but it's often what happens. And if we can think about it as a system and identify the components of it, we can identify the breach and repair it. And that allows us to be successful in the future. So another way to look at trust is the elements or behaviors that are specific. So this is a useful acronym. You can read more about it. Boundaries, reliability, accountability, vaults, or confidentiality, integrity, non-judgment, and generosity. If we can identify where on our teams this broke down, we can talk about and think about how to fix it because we have a behavior and then we can counteract that behavior. So this talk is about resilience sort of, but really it's about trust. And again, the reason that I say that is that I think when things fail, often the consequences that we lose trust. Whether that's in our tools or our team or the organization or our users. And we can't bounce back unless we repair that trust effectively and we create an effective solution. Thanks.