 Limana Musashi wrote, A Book of Five Rings is a guide to anyone who wanted to achieve enlightenment in the way of the warrior or the way of strategy. He gave us nine principles to guide us on that path, and that's what we're going to talk about today. His first principle is do not think dishonestly. Now he's a warrior, so it was okay for him to behave dishonestly. I don't want anybody here to do that, but let's be honest in our minds about the task ahead of us, the difficulty, and whether things are working or not. The way this is going to work, I'm going to give his principle and then my little commentary. This is the foundation for all of his teachings and is a great foundation for us and whatever our DevOps journey means that we're going to be honest and candid about what's working. The second principle is to become acquainted with every art, I hope. Come on, slide. Oh, no, the way isn't training. There we go. See? Musashi talks about this throughout the book, that the most important thing you can do is to study. Now we can go to conferences and we can read blog posts and we can wear T-shirts, but the only real way we achieve mastery in DevOps or whatever our particular profession is, is to do it. The time you spend in front of the keyboard practicing the techniques people talk about or with your coworkers is more meaningful than anything else you're going to do with your time. Focus on this. The third principle is to become acquainted with every art. Samurai's were certainly warriors, but the best were also authors and poets and musicians and artists. Musashi was an accomplished metalsmith and woodworker. And I think in our world there's a great parallel here to the full stack developer and the need to be conversant across the stack. Specialization is important, but generalization so that you're able to think about all elements of the environment you're working in is, I think, quite a bit more important. Along with that is our next principle, which is to become acquainted to know the ways of all professions. It'll shock you to hear that as a young system administrator I held my marketing colleagues, my sales colleagues, finance, basically anybody who wasn't an engineer in utter contempt. That isn't actually a really good way to operate. And by learning about their professions and learning about their problems, I found a foundation for organizational empathy, which is the gateway to collaboration. There couldn't be a more meaningful tenant of DevOps than to collaborate, and that comes through empathy and understanding what your coworkers are doing. The fifth principle is to distinguish between gain and loss and worldly matters. This is a little bit hard for me to think of in the context of Musashi, but certainly in a military campaign, if you have won a particular battle but lost all of your troops, you've likely won the war, and you've got to be mindful of that. In our case, I think when we're talking about DevOps or new systems or new processes, set out achievable or maybe stretch goals with clear success metrics and measurable ways to know whether you're succeeding or not. This harkens back to our first principle, which is to be honest about what's working. The sixth one is tough, intuitive judgment and understanding of everything. That's a pretty high bar, but I think it speaks also to our need in DevOps to iterate into better and more clear understandings of our incidents and the way we handle them. For me, this is pattern recognition, which develops out of running open and honest postmortems that are based on factual data. Through that process, you get to a much better place for pattern recognition and intuitive judgment and understanding of everything. The seventh principle, perceive those things which cannot be seen. He's talking again about what might be happening with your enemy on the battlefield. In our case, if you haven't heard people say measure everything enough at a conference and you haven't been going to enough conferences, but it's true. This is why we measure everything. We can't be mindful of the entire environment in all cases at all times, but if we're using measurements, we can go and look and have perception about the things that occurred when we weren't watching them. It's very important. The eighth is pay attention even to trifles. And here again, Musashi is talking about a flick of a sword or maybe the movement of a cavalry unit somewhere. But in our case, big things, big incidents usually start with a very small change in the fact pattern. If you're thinking about organizational change or you're thinking about changing the way a team operates or reinventing a system or a service, that's great, but you've got to keep what you're doing going. You've got a business and an environment to keep moving and you can't lose sight of the little things while you're striving for the great things. The ninth one is my absolute favorite, do nothing which is of no use. Now this guy was a ronin and eschewed all worldly delights to perfect his craft. I'm gonna go have a beer with everybody later and it's hard to see the utility in that. But when you think about what you do day to day, so much of what we complain about is waste. I have no better commentary than what you see here, do nothing which is of no use. If a process or a system isn't useful, quit doing it, find something that is. The last one is a bonus round. It's not actually one of his principles, but he tells us that the way of the warrior is resolute acceptance of death. Knowing you're going to die. Let's not go there and devops, but let's absolutely be certain that things are going to fail and things are going to crash and things are going to go down. And it's more important for us to be able to respond to that than to try to achieve some other level of perfection. Thanks everybody. I'm Matthew Beckman. All right.