You. Hi everyone, thank you for joining in this talk about platform engineering adoption. I hope you will enjoy and learn a lot from my presentation. So let's start. I have prepared today for you a talk about three practices that will ensure the success behind platform engineering adoption and make it more smooth. Right. This is based on my experience and why I feel confident to talk about this to you. Well, during my years working, I had the chance to work in Red Hat enabling stream alignment teams and also platform teams. I worked in the open innovation Labs team here in Ladam delivering the DevOps mindset and practices in different companies. And also in my previous year I worked in display in the global it center providing a platform as a service for development teams, providing the platforms that will help them implement DevOps practices like CACD code versioning. So I participate and lead that platform team there. So all the things I will talk for you today will be based on this experience. So if you have questions or doubts, just reach me out in the LinkedIn or you can write me an email if you want. Right? So what I have prepared for today is the three steps presentation. First of all, we will go through what is platform engineering, the what and why, why we should implement platform engineering, what is the benefits? Then after understanding the benefits of platform engineering, we will talk about the challenges, the roadstones, because not all paths are easy, right? So it's important to understand them and be cautious with them to avoid the typical errors. Even when we are adopting other kind of cultures and practices, some of them are very common between them. And last but not least, we will talk about the three practices I mentioned at the beginning break and the reason for this presentation. To avoid the possibility to fail or fall down with the rollstones, this path of platform engineering adoption has. So let's start with the intro, the what and why of platform engineering. So what is platform Engineering? It's a discipline. This is the description you will be able to find in platformengineering.org webpage. It was defined by Lucas Galante, one of the leaders of platform engineering movement. So he defines platform engineering as a discipline. Discipline is basically something that several people is doing, doing, trying to implement, right? But it's not just a discipline, it's a discipline of designing and building toolchains and workflows. And when he talks about workflows and tool chains, let's talk about first tool chains. Tool chains is a group of tools integrated and fully configured to work together. And workflows means how people work. So we are talking about them together, right? The platform engineering practice is focused on generate them together to obviously enable self services capabilities for software engineering organizations in this cloud native era. So Lucas Galante was seeking to find this thing for this definition of platform engineering to make it understandable and generate this sharing understanding that is a practice is the discipline of reducing the cognitive load of the rest of the teams to focus on their core business and have internal customers using this platform as a self service and reducing the possibilities of them to fail. Because they need to learn and develop skills that are not focused on or are not related with the core business they should be focusing. Right? So why we are looking for platform engineering? Why companies are looking for platform engineering first of all is the standardization and control. Because if you have all teams in your company working as they want or with the tools they want, or even with the same tools, but implementing the tools as they can or as they understand, it's difficult to maintain, it's difficult to support at long in the time, and also it's difficult to control how people is managing these platforms to take the real profit and to really implement the best practices. All companies are trying to promote mainly behind the concept of DevOps. So platform engineering and DevOps will be very connected. Even some speakers of platform engineering are saying that platform engineering is the next level of DevOps. The next benefit is reduction of cognitive load. The platform team will focus on have the skills to prepare the platforms for product teams and avoiding them to have this knowledge that is not really needed to build and deploy their own applications, their own it core business. So they will only will use in a smooth way these platforms, reducing the knowledge they should need or the expertise they should need to keep like platforms of CI CD to run and build their applications or platforms to deploy the applications and manage the error environments. Also something that will improve is the reliability and stability because we will have an internal team focus on the internal customer which will be these stream aligned teams, dev teams or product teams. So they will focus to have a real strong platform where the internal customers will work over to promote a better service for external users. So it has a lot of benefits for companies that are implementing, but it's not a smooth process. If you don't take care of the main Roadstones, we will look here. So if you want to go deeper before to go to the Roadstones, if you want to go deeper on platform engineering, I will recommend these talks that are available in the library platform engineering YouTube channel. First of all, Manuel Pay is one of the writers of team Topology's book were born this concept of platform engine, platform teams. He talks about what is a platform as a product and this is one of the topics we will be talking here and is strongly related with one of the roadstones we need to identify and work on. The other one is Mayuri Hyde is one of the collaborators of Lucas Galante in this platform engineering community. She's so smart and based on her experience she talks about what's happening with DevOps and platform engineering as practices, as movement, how they work together and finally, but it's really important, the state of DevOps report for this year 2023, focus 100% on platform engineering. So if you want to know more how platform engineering is impacting in the world, you can check the information in the DevOps report. What are the Roadstones? Where are the challenges behind platform engineering adoption? Because sounds very great to have platform teams inside my company taking care of platforms and solving the live for my product teams and they will be able to focus on only develop and build their applications without the need to learn about how to implement CI CD or how to implement cloud native deployments. Everything will be ready for them, right? How we can adopt this way of working smoothly without the failure that some companies had experienced in the past. So what are these problems? Right. First of all, we need to understand that one thing is what we believe, right? There is no easy path to success. Everything we will do will have challenge. So we need to take care of this, that platform engineering, even when it sounds amazing as all the benefits it brings, it's important to understand that it's not a smooth adoption, it's something that you need to take care because will have a huge impact. Because we are talking about teams that will focus in internal customers and they will provide services for all platform, all product teams that will be using their platforms to build other platforms or applications to external users. So it has a direct impact on the business of a company, even when it's for internal customers, right? So what are the main challenges? First of all, all companies are in the same path, right? They are lack on time, but they are receiving high demand. Anyone is with enough time to look at the applications or look at the platforms in the infrastructure and take the time to solve issues, solve bugs. They are all day working, they are delayed on features, they are delayed in things they need to do. So this is one of the main challenges in any adoption processes and here with platform engineering is one of the possibilities to generate failures in your path. The other thing is ways of working and thinking. The companies that are implementing platform engineering is something for medium and big companies, it's not for small companies because in small companies there are small teams. Truly 100% focus on everything needed for their business, right. Small companies will not spend in, have just one team for internal customers and prepare platform for the rest. When they have two or three or five teams inside, or sometimes they are externalizing the service. So when we are talking about big companies or medium companies, we are talking about a big number, huge number of teams working together. And when we talk about people working together, they have their own ways of working based on the experience they learning from other companies and the agreements they have inside the team, right? So it's so hard to not face out problems or to not find detractors in an adopting process. And here in platform engineering, adoption is the second possibility of failure. And last but not least, people is behind this, right? And today we have a huge problem in it, which is the rotation of people, right. And how to keep people aware, keep people motivated, right? So this is another of the problems we will probably face out. So the first one is lack of time and high demand as I mentioned, right, because it's a matter of time we need to deliver. We have the challenge in the marketplace. All companies are trying to win, right? So all time they are running, they want to deliver new features, they want to be competitive. So there is no time to be asked to achieve their expertise in all tools. Let's talk about the product team when they are developing a new application or developing a new feature of our application and they need to start using new architecture solutions or they need to change how they are implementing their applications. There is no time enough to be expert on how we will deploy my API or how I will compile and manage my secrets or integrate my secret management tool with my cloud platform as a service. So this lack of knowledge at time will be generating tech depth for the team and at some time it will request the price, right? And the other thing is develop new skills. If they need to develop the skills to work over the application, it's a core business for them. They will not have the time for learn other skills like how to manage the platform in production. Right? This should be shared with other teams to focus on generate better skills inside the team. Rely on failures and outages, reply on failures and outages if a product team needs to reply to their failures and outages in their core business application, what will happen? If they need to reply also to the platforms they use during the development and deployment process and keep the documentation updated. It's part of the development or the product team live to document everything, but also if they need to document the platforms they are using will increase more and more. The dependency and the depth they have in the time. So the demand is also a problem because it will just increase. When you are doing the things good, the demand will start to increase. So let's imagine that we have a platform team supporting these product teams that are developing applications and now they have a cognitive load reduced. But now more and more teams will start to use the platform. And also if we don't have a platform team, we have only one team developing and now more teams are appearing because we have new business cases and we need more applications. All them will try to use the same platform. And this platform that start to be strategic will start to be the point of failure, because each team will try to do with their own ways of working and more users will appear with more doubts, more requests, more problems, right? That's the problem of demand and lack of time behind platform engineering adoption. And what about ways of working and thinking? It's very likely that you will encounter people that are not agreeing with you, right? Several times you will find detractors because they want to do how they are doing, as always, right? Because they know how to do. They understand that like this way it will work, right? And what about the compliance flows? What about the processes that are defined by the company and we need to follow? Sometimes this will stop the innovation, it will stop how we can make platform easily to be consumed by developers, by teams that are behind the software delivery lifecycle. And sometimes also we will see two specific requirements, right? So specific at the level that you will not be able to understand if this will be positive for the team or it's more a bottleneck to achieve the agreements and to achieve the generation of the MVP or the solution to achieve the market time. Like some other problems related to ways of working and thinking, what about teams that have different priorities? Now I want to have my platform working here, but the other team is thinking how I can building for these other platforms and the language and understanding barriers. Because sometimes companies are so big that they have teams in different countries. I have suffered this in some of the companies I worked for my luck, I can speak different languages, but some teams in specific countries, they don't have this luck. And sometimes when they need to trade with other teams, it's difficult to remove this barrier and generate the shared understanding, right? And last but not least, keep the team engaged right? Behind everything, behind technology, behind platforms, we have people, people that can be influenced by their situation, their ways of thinking with clear cognitive limits, right. Without understanding if they can code test, manage the CI CD platform, manage the code quality platform and all the rules behind it, the configurations with a lot of market temptation and with a technical and practice dev. Because we will not find probably all seniors engineers we want to have, right? Our market is full of different engineers with different flavors and it will depend a lot on how they can work together to improve this experience. So what are the three practices I have prepared to win and face out these roadstones and be able to jump over them, right. The keys of success I have prepared for you and I have implemented in some of the teams I have worked with good results. The first thing is customer centric leadership as I mentioned it, and you will be able to see in the videos and talks I share with you. Platform engineering generates a clear vision of an internal customer. So this platform team, they will need to focus and have very clear and identify this customer. What is basically the product teams or depending on the platform you are working right or you are building. So the proximity to these teams is very important for product teams and this leader that is guiding the team should promote continuously this proximity, this vision of customer, internal customer and guiding the team based on objectives, goals that will generate the clear understanding of priority. What is the needs, the real needs of my customer? Generating a platform that will work for them, not for the rest of the companies in the market. We need to focus on the real needs of our internal customer because sometimes this company has their own policies, their own ways of work and the platform should work for them without reducing all the cognitive load of this platform. Of these product teams that will use the platform to start using this should be smooth at the level that they will just onboard the application and start coding and focusing on their core business. So this leadership with customer centric vision is clear, is key for success to remove all the problems behind the time and demand because he will be able to decide what the platform team should be doing and what they should be focusing in the moment based on the real needs of the customers. One other thing we have here is practice what you preach, right? If you are building a platform team and this platform team is creating tool, is preparing tools and ways of working, try to generate metrics, metrics to measure how teams are using these platforms and these ways of working, but also use these metrics to measure platform team, right. How they are using this platform. To not only say hey man, use my platform but I'm not using it. I don't know how it works because from real life, the platform team will understand how the platform itself should work, how the flow should be, because they will leave it from their experience, removing the dependency of ways of working on how people think, because they will live in their own life, their own day to day, how to use these tools and to measure, same way as product teams should be measuring the platform and also will help them to keep engaged, right, because they should be using the tool as they are promoting to be used. The other practice is form champions. We cannot have the expertise, the specific knowledge in all tools we are promoting in a platform that we are offering as a service. Because a platform inside a company is a toolbox. It's a group of tools interconnected and prepared to be used in an easy way inside this specific company. I'm talking about platforms, not only the technology itself, but also the infrastructure. This platform team will need to work on documentation, configuration, solve bugs, a lot of the things. So the general knowledge is a must for all of them. We are talking about t shaped people, right? T shaped group of people. But to form this deep knowledge, they should not go through all platforms they have in the tool chain. But instead of that, you should have champions for each technology. Obviously they should have an understanding, the whole team should have an understanding, a shared understanding. And this will be the responsibility of the champions also to reduce the cognitive load of the leader of the platform team, guiding the rest of the team to work over the specific platforms. They have the expertise. In summary, we have these three practices, right? The customer centric leadership. They need to have a clear image of the customer. I mean the platform team. They need to understand that they have these product teams inside the company and they need to provide the platform for them based on their real needs. So the targeted objectives need to be clear also and promote the closeness with the customer. So this leadership will be one of the keys of success. And if you have decided who is the best leader for your team, for sure you will have one part of your path with a real high probability to have success. But the importance of the customer centric vision for this leader is critical. The second practices is practice what you preach. If you have one platform, understand, define what is the metrics to measure people using this platform and use these metrics to measure the platform team also and force them to use the platform to build the platform right and recognize and show achievements. What is better to show what a platform is generating benefits. If you can show from your experience here, you can come with DevOps practices like the showcases and demo days well come from agile world also. But to show from the team, the platform team, how platform should be used from the experience, the real experience. And last but not least, this practice is very important. I have been using in all companies I have worked is farm champions because one person cannot have all the knowledge, deeply knowledge and all platforms, all technologies we are working, right? So form experts by tool and delegate to them that they should lead that specific tool as part of the group, they should promoting which kind of trainings the rest of the team should be doing, how to structure the documentation, how to implement a configuration. They should be this lead because the lead of a platform team will not have enough time just to be expert on all tools. They will be managed, right. And trust on them. The champions should be people that are fully encouraged to work as a champion inside the team. So they should be these heroes of each tool, but not behind unicorns inside the team, right? We don't want to generate people that cannot be replaced or people that cannot have a background backup, right? So these champions should be training and sharing the knowledge they have with the rest of the team to fill the gaps, right? And the leader should be promoting and delegating this vision and deciding who will be the experts of each tool. This is another of the real good practices I have implemented and have worked for me. So just to finalize, if you want to go even more deep on these three practices, I have been implemented also. Nick Watt that talk in the platform Engineering conference in 2022 talked about people, processes and platform a community focused approach. This talk will reinforce you the three practices I'm showing you today, and you will be able to find much more of platform engineering, the YouTube channel and also in the platform engineering webpage, platformengineering.org. I would invite you to get involved in this movement and share your experiences and your keys of success, your practices to reduce the failures in the past. Because as idea platform engineering have helped a lot of companies to go through their challenges and achieve the metrics and results they have been expecting. So thank you for your time. I hope you have enjoyed this presentation and if you have doubts you can reach me out in the chat or through the LinkedIn link, find me in LinkedIn or write me an email. I will be able to participate and collaborate with you in any time. Thank you and have a nice day.