Hi everyone, welcome to my talk. Today we'll review platform engineering concept, how it's connected with DevOps. Furthermore, I brought up some practices I hope will ensure you a smooth adopting of platform engineering. My name is Caillou Medeiros and currently I'm leading the DevOps adoption at Citi. And why me to talk about this concept today? Well, I had the chances to work directly with the stream aligned teams, enabling them, participating with them to generate it products and have the happy customer at the end. But also I had the chance to work with platform teams at Citi, Red Hat and Slay. Actually I lead one of them generating a DevOps tool chain for ensuring this platform reliable and stable for all decision alignment teams we had inside the company. If you want to know more about me, you have here my LinkedIn, my email and my web portfolio in GitHub pages. So let's start what I have prepared for you today. Usually I start generating shared understanding on the concepts we will review. So I will introduce DevOps and platform engineering. For sure you have an understanding of this, but usually different people will have different definitions. I like to start generating this shared understanding and then we will go to the adoption journey. Why and how they should be together. Finally, I will introduce the three practices. I promise you, I hope them ensure this smooth adoption. As I mentioned at great. So let's start with the introduction to DevOps and platform engineering. What is DevOps? First, if I ask to anyone here for sure you will say your understanding of DevOps. But I like to introduce DevOps using the first phrase of the DevOps handbook, which is the main source of knowledge about DevOps. It starts with this. Imagine a world where pos dev engineers, qa it ops and infosec engineers. All the roles, the typical roles we have inside a traditional or even a modern IT organization. Imagine them working together without barriers, without sidos, without the normal boundaries we have defined by the traditional organization or the topologies we have inside the organization, not only to help each other with their needs, but also to ensure the overall organization succeed. Which basically means have our end user or our customers happy with the id products we are generating as it organization. So that's the understanding that Jenny King, John Witties, Patrick Devois and Nicole Forrest Green tried to bring to us in this book. But when we have this kind of adoptions, the DevOps adoptions, right, the adoption inside companies. Basically people will try to implement different ways of working. For sure it will be connected with agile adoptions, lean the software development, adopting, design thinking, adoption and it will be connected also with technologies, not just a matter of cultural norms and ways of working. We will have libraries, tools to go from ideation, to understand the needs of our customers, to have something in production solving the problems of our customers. So we will go into this mobile loop that DevOps provides to us to plan, code, build, test, release, deploy, operate and monitor, and we will be there till the product ends his time. The problem will be that where each of these roles, they will need to have the set of cultural norms, the ways of working and the tools they require each role, right? Furthermore, of the mindset, the DevOps mindset and principles. But when we are talking about the DevOps world, we are talking about a lot, a large list of tools we can use, right? We need to decide which one we will use and when. We have different teams inside our organization. For sure, one team will use one tool, another teams, they will use other tools because if you don't have management and standardization, it will happen. I already had this experience mainly when the organizations are lead by different managers. In addition to that, the teams will need to support these platforms to keep them working, reliable and stable to use them during the whole lifecycle of the software development. If not, something will block the generation of value there is where platform engineering born. The first introduction of platform team was in the team topologies book written by Matthew Skelton and Manuel Pais. They described platform teams as this string alignment team, this product team that will provide an internal product as platform which these string alignment teams, these teams with different roles working together, will use as a service. So platform engineering was described as a discipline to design and build these tool chains, these platforms that will be used as self service to help the engineering teams that are generating it products for end users to phase out this new cloud native era. You will find this description in the platform engineering community page. You can just type platformengineering.org there. There are much more information about platform engineering. I encourage you to go there and investigate on why not participate in the community. So platform engineering is that idea where we have an internal team inside the company and they are solving and reducing the cognitive load of string alignment teams to only focus and have their real needed skills to work in their specific IT product. So the platform teams just giving an example will provide these tool chains or the set of tools needed to perform the typical tasks, repetitive tasks that the stream aligner teams have, providing not only the platforms itself but also the templates, the golden paths and managing these platforms to keep them reliable and stable. So more or less we can understand where they are connected, right? The adoption journey on why and how they work together is clear now, more or less. So let's go into the benefits if we have platform teams supporting these stream aligned teams which are trying to work together with all these roles to make the organization succeed. First of all, as I mentioned before, if you have different teams without a clear management and aligned management, for sure they will start to use different platforms to do the same thing. Let's have an example to build and deploy one software component. I already had experience in other companies where one team was using Jenkins, another team was using Travis CI or any other tool, right? Basically in the same company they are using different tools. So for sure they will face different issues that will block them and will not have a chance to share knowledge, share learning lessons because they are using different tools. The chance will be a bit more or less right at the end, the standardization is needed to have the right control over the practices we are implementing inside the company and to have success on a DevOps adoption for sure. I don't want to remove the freedom of teams, but they should have boundaries. Platform engineering will provide these boundaries because at the end we will have an internal team trying to generate an internal product and combines the rest of the teams to use this tool, this platform. They will provide a standardization ways of working standardization and also they will provide this control to understand who is doing what, how they are doing and where is the boundaries they have to manage the different ways of working. Also we will have reduction of the cognitive load because in the beginning without platform teams, if we are in a DevOps adoption journey, we had to hire engineers with knowledge not only in develop code but also to operate the software or even to manage the CI CD tool. Removing this dependency or the requirement of these skills, we will be able to find more engineers. And also we will reduce the stress of our engineers inside product teams to not only develop the active product but also to maintain their own tools. And finally, the tools will be more reliable, the platforms will be more reliable and stable, avoiding any blocker in the software development lifecycle related to the platforms needed to build, develop, verify the code or even operate the code. So let's take an example of these two lines. Right where we have in the first line is Rina line, a team trying to take one idea from left and generate a product to have a happy customer to the right. In any process to generate an IT product we will have rocks on the wall and sometimes we will have mountains. So only having string aligned teams, if you are entering to a traditional organization and breaking down the barriers and rearming all the teams to have all these roles together, to work together, as DevOps description express, to generate success inside the company. Sometimes we will have the people going outside of the stream aligner team to push the rest of the team because they will depend on the specific knowledge of that person. Mainly if we are talking about platforms that will support the work that the stream aligned teams are doing. If you need someone that will restart the Jenkins instance, or if you need someone that will manage the configuration of your kubernetes or graphana stack at the end, someone inside the team will have the specific knowledge and they will waste their time. They were focusing on generate value for the end customer to support the daily work of the team. It's different if we have a platform team looking to all these issues, possible issues for sure. It will not remove the whole rocks on the road or the whole mountains we need to cross over, but they will simplify the path to be faster than just having a screen aligned things and reach before the success. Having our happy customer at the end of the path. And even they will be faster to have a fast or quick feedback loops which will generate better software and more satisfaction in the customer to make our organization win in the marketplace. So if you want to go deeper in this concept and the connection between DevOps and platform engineering, I will recommend you the talks of Manual PI's platform as a product and mayori high DevOps ain't that but we got a talk because they introduce more and more on this concept. And finally the state of DevOps. The report from 2023. They focus 100% on platform engineering and how this practice is important to face out the challenges proposed by DevOps in the last years. So now we reach the three practices I had prepared for you. I used these practices in the past, but first I want to generate a sense of why we need these practices. So I will introduce some challenges behind platform engineering. Adopting first of all, DevOps and platform engineering is not something that is easy to do, right? It seems like we need to do that will be a total success. That is what I need to have. And after this talk, you will reach your manager. You will try to push the platform engineering ideas inside your company. But it's not an easier thing, right? Probably will be harder. But don't get sad, right? There are ways to face out the challenges we usually will have. Not only the platform engineering adoption, some of them are related to any transformation process. First of all, lack of time and high demand because when we are introducing a platform team inside a company, first of all, everyone will be busy. So it's difficult to motivate people to adopt a new platform and the demand will just increase. If you have success with one team, everyone will want to have this platform as well. Ways of working and thinking usually we don't have just one team inside a company. We will have a lot of teams and they will bring with their ideas, their BSS, their ways of working, because they work like that in other companies. And these platform teams, they will be in the middle. So the facilitation will be a mess if you don't have the platform team prepared. And finally, the people motivation and the rotation of IT engineers is a huge problem for all initiatives we have today inside the IT organization. So let's go a bit deeper inside each of these challenges. First of all, if we have platform teams, they will need to manage platforms. And platforms are not just one tool. The expertise on these tools will be one of the challenges. How you can keep the expertise inside the team, how this expertise can be put in benefit of the internal customers, the swing alignment teams, and to develop these skills inside the string alignment teams. Because even when we are providing a platform with templates and golden pads inside the srina teams, they need to develop some skills to take real profit of the platforms that platform thinking provide. How we can reply in front of failures and outages, because they will happen and the documentation that needs to be updated. Everything will go so fast. At the same time we need to manage the demand, because if we are introducing a platform team inside a company, usually if it ends in a success case, for sure, managers will try to push this to the rest of the teams. So more users means more doubts, more requests and the team need to be prepared for these challenges. In other side, we have the ways of working the facilitation between teams, right? Because several ways of doing the same thing. As I mentioned before, sometimes we will have just a simple case, sometimes we will have one team using one CI tool, another teams using other CI tools, and the different ways of configuring and provide environments and provide resources will be a mess. So the facilitation to put the platform team in middle of this will be a challenge for sure. Also they will need to face out complex compliance flows. Because in all companies we have these kind of problems with specific requirements, distorted perspectives of priorities. And the last thing I had seen in the last companies and teams I had worked after the COVID we start working globally with people from different countries and the languages and the understanding barriers sometimes generate a lot of confusion. Finally, keep team engaged. This is another challenge, a huge challenge, because not only related with platform engineering, it's in all cases inside the IT organization. People is burning out and the cognitive load is directly related to this. How the platform teams can manage this cognitive load, as I mentioned it, the time will be a problem, the demand would be a problem. So it's super easy to get burned out. Of course, the technical and practice debts will add more challenges to this. So how we can face it. There you have my three practices. The first one is customer centric leadership. Right inside each platform team, we should have a leader with a design thinking mindset to identify the customers, the internal customers. These string alignment teams understand the real needs because for sure, if we have platform teams in different companies to provide the same type of platform, they will identify different objectives, different needs, because each organization has their own conditions, their own requirements. So it's super important to put in the place of the customers and understand their objectives, to guide the priorities of the team. And also this leader should connect the platform team, the whole platform team with the customers. How this leader can do that promoting inside the team to map and make it visible, the profile of our end users. You can use empathy mapping proto or user Persona. For mapping these profiles, it's crucial to have the design thinking mindset. It will provide you this perspective that this is my end user and I want to satisfy their needs. The second practice is practice what you preach sounds super logical, but I had a lot of experiences where the platform teams, they were not using their own platform and was a mess because at the end they don't know what is happening, really happening in production. The better way to understand how users are living or they are implementing the platform is using it. Metrics is the perfect way to measure this, to take a control of this. So setting the right metrics will be good to identify and monitor during the time if the team is really using the platform and it can be complemented with the internal and external usability testing. I mean you will invite not only people outside of your team, but inside your team to execute and run usability testing. Go navigate through the platform and the offering the platform team is providing and test it before to release a new version to reduction. Also have showcases and demo days to promote your platform and motivate people to get into the platform and start using and finally run this kind of lighting talks or tech talks because then you will share your knowledge to the rest of the teams on how this platform should be used. It will generate a better understanding of your end user and how to improve the platform experience. Finally, form champions. This is the practice that I love more because when we are talking about platform teams, usually it's not just one technology. We will have more than one technology, more than one library, more than one platform to generate one single platform to support different needs of these. So the knowledge needed to manage all these platforms is crazy, right? I had the chance to lead a platform team where we were providing DevOps tool chain to versionate their code, to build their code, deploy their code. So a lot of platforms in all these stages, right? Not only to build, but also to scan and generate automation in the test phases. So what is the keys there of this practice? The whole team should be generalist. I'm talking about the t shaped people, right? They should be generalist in all tools and platforms you have inside the platform team. And some of them will be deeper in specific platforms to generate ownership and delegate the responsibilities and keep the documentation updated and bring news to the team, solve issues and generate more expertise in the rest of the team. So with this, you will stop to search for experts and you need to start forming them stop to search for experts because for sure you will find some experts in the marketplace, but they will be so expensive. I will not say that you need to stop to search for experts and sometimes it will be needed. But if you can avoid it, try to find people that you can form and generate the t shaped people inside your platform team because it will maintain low the cognitive load and hide the expertise for that. First of all, you need to have a career path for each member and this career path should be aligned with the team needs. And at the end, the end user needs the internal teams, right? The stream aligned teams with that career. You will have certification training paths for all members inside your team, not only to be generalists in the platform, but also to be deeper in one specific platform. Complement that with game days and Chow's engineering sessions where they will need to prepare the platform to fail and solve it during a real and live moment. Finally, assign and create a calendar of lighting talks and tech talks that is connected with the other practices to these champions, to be led by these champions, because then they will learn more to be prepared to talk about those concepts. So, to summarize the three practices I broke to you today and ensure a smooth adoption of platform engineering inside your company. As you already reviewed with me, platform engineering is useful to support the DevOps adoption and ensure that the whole organization the IT organization. All the different roles we have inside work together to make the organization succeed. Try to bring this to your teams right? And also you can use it in other teams as well if you feel that is useful. First of all, customer centric leadership. We need to have one leader with design thinking mindset, with a clear vision of our customers and sharing this information with the rest of the platform team, promoting the closeness with the customers and setting and aligning the objectives and goals to address the platform team success. Because at the end, if a platform is not good enough, it will not be adapted and it will be a failure. Then let's practice what you preach. If you are proposing a platform to the internal users internal teams, then you need to use it as an internal team as well. Set some shared metrics with you and the end users and recognize and show the achievements because then people will get more motivated to find improvements inside the platform. Finally, form champions because it's super hard to find people ready to work in a platform team. So find generalist formed experts by two and delegate and trust on them. Trust on them that the documentation will be updated. They will bring the ideas to work in the specific platforms they are expert and to make the platform better. Finally, just to close this talk, I will empower you to go to the platform engineering community page, read the nagging steps to platform engineering hell that Lucas Galante published some time ago. You will find there are some mistakes in the platform engineering adoption you can avoid, and also I empower you to watch the Nick Watt talk about people, process and platform. Finally, if you want to join the platform engineering YouTube chat channel, there you will find much more content to prepare your path or your career as platform engineer. Thanks for joining. Thanks for participating. I hope you are enjoying this event and have a nice day.