 My name is Ahmed Bebarz. I'm a software engineer at The New York Times. So I'm here to talk about platform engineering from my perspective. So our story is a story. So 15 years ago, when I was starting as a software engineer and doing web applications, I joined a company where I have to build admin bannals. So my first task for the first month was to have a website application. We need to build a backend for it. And that took me about a month from authentication, other components, user registration, all of the kind of components. And that was my first task. And it was like a month to build an admin balance. That's great. Then the second one was very similar, but just different business requirements. So it took me about two weeks. And then after a week, a few weeks, so at the end of the day, I found myself like building the same thing over and over, but just switching different components between every application depend on the business requirement. So basically, that's how I call it platform engineering, how you build composable components for engineers to build their services through. So the way I would like to describe it as a developer journey, when an engineer starts to think about like, I want to build a new service, how I want to build this service, you start to think like, here's my idea. I want to plan it, and then I do a design. And then the rest of the steps from creation, code, like the build stage, monitor, all of that kind of steps are pretty the same. They are different from different components, different tooling, but they are all kind of the same. So at the New York Times, we looked at all of the steps and decided like, how can we make this process and developer experience much better? How we give our engineers a better developer journey so they can build worse. So we defined it as workflows. So we defined multiple workflows for engineers to walk through when they decide to build their service until like they get their service ready in production. And you can see here, like here's all the workflows that we have walked through and built. So let me give you an example, and this is an actual example. As a developer, I want to build my service. So as an engineer, I will go to the create step or the onboarding process. I will say like, I'm from team A, I want to build the service in Go, and it's dockerized, and it has a public interface. That's all I need to say at the initial onboarding step. Once I've done this, which takes me about five minutes, I will just like go find a repo or a GitHub story where it's like all of the code and all of the templates that I have. And actually, my entire service is being built and have all of the components from a CI, CD, runtime, cloud resources, and Ingress as well. So like the entire steps take about five to 15 minutes to build a new service, and then I get all of the necessary tooling around. So the idea here is all I had to do as an engineer is just like to think about what exactly that I need to have my service to do. So I need to build a login service, authentication service, crew bone service, whatever I need to build, all of the tools are here that I can use to just start implementing my logic. What we are trying to do is building a developer experience that makes it easier for engineers not to have to reinvent every time they think about how to build a new service for themselves. And the takeaways from this process that we have built inside the organization is, first of all, if we wanna build a platform engineer as a self-service, we have to have a user documentation to ensure that users don't have to ask too many questions. We still have to support them, but user documentation is pretty critical to them to be able to self-service their requirements. Adoption, we are in the second year of building an internal platform at the New York Times. So we have to work and partnership with many teams to ensure that we understand the requirements that they need for their services. The most important thing for us is to think about the platform as a product. It's not a project. So it's not a one-time thing that we're gonna build and just move over with. It's just multiple iterations that we have to go through. So it will take time to get mature and understand what we really need to build in the organization, what kind of concepts that we need to rely on. And at the end of the day, customer feedback is important. You need to have a new star metric for your implementation and for your platform. So you can understand how you evolve from year to year, week to week, month to month over. So you would have a really good experience for your engineers. And that's about it. Thank you all.