 Getting started with DevOps is a big thing. Based on our own experience, one of the biggest things I recommend to people is, think about telemetry. Telemetry is the lifeblood of running a service, and you'll never have enough. But coming from a team that was box product software, adding telemetry was never a focus for us. Moving to DevOps, it's become hugely important. The first thing is adding telemetry, making sure that I could actually run a service for a customer and do it at high quality. Another thing is making sure that people understand how to diagnose and repair problems that do happen in production. Having troubleshooting guides, having knowledge-based articles, whatever you want to call them, but having some place where when a particular problem occurs, how should somebody deal with it? So that when you also introduce the notion of an on-call engineer, how is that on-call engineer going to be able to handle problems when you have a large service or set of services like we do? Having that knowledge base is really important. Also, the engineers are using different tools to diagnose and understand problems in production, then they use on a daily basis. As a result, training becomes very, very important in the DevOps transformation. To help people understand what's available, what does the data mean, we have to understand how to query it, what trace points are available to you, because we can produce an enormous amount of data from the service. So we have a ways to control how much is actually produced at any given time. So being able to understand what options are available to a person in terms of getting extra data when they start to narrow down the problem, this is very important. So telemetry is hugely important. It's a big part of the transformation, understanding how to diagnose problems in production, understanding the tools that you're gonna use to diagnose problems in production, being able to have alerting and other mechanisms that help you understand that problems are happening before, hopefully they affect customers, so that you don't have to wait until somebody calls you and tells you you have a problem. When we finish a sprint and we deploy that sprint, sprint really has to be done. And that's a big shift for coming from a box product methodology where even though you're using Scrum or some other agile process, getting to the end of the sprint, if it's not actually hitting customers' hands, it's very easy to say, well, I'll kind of let this slide because I need to go on to the next thing. And as a software engineer, many of us got into writing software to begin with because we love producing something that people use. So you get both the responsibility of making sure that when you finish the sprint, the code really is done, but you get the reward of because you did that work, you got it to a customer, they're hopefully very happy with what you created. And if you need to make any improvements, you know about it immediately and you can fact that into your upcoming plans.