Hello, everybody. Welcome to our talk, Principles of Team Topologies and Platform Engineering. hello everyone. My name is Valionchev and, over the past seven years or so, I've been working very closely with Jansu, building platforms in many different environments, different. Business domains, different technologies. We're not going to talk only about platforms in the cloud native context. We're going to cover platforms in any other kind of context. That's me. Over to you Jansu to tell us about you. My name is Jansu. I'm an architect in Red Hat and as Val said that I'm mainly focusing on building the platforms that help organizations that fits for their needs and goals and their purposes. And also, helping to, build the platform teams that are like high functioning, self sufficient and able to maintain and sustain the platforms that we built together. Let's start that. Let's start. I'm actually representing here Team Topologist and leading the team at Team Topologist. I'll let Johnson talk about it. It's so cool. If you haven't heard about, Team Topologies, or, if you haven't had a chance to read it, we highly suggest you to do it because it is one of the best product management book and best, one of the best leadership book out there. If you want to know more, you can go to the website teamtopologies. com or, if you like what you read and if you like what you hear today, you can also contact us to learn more. but. Unfortunately, we have 30 minutes in here, so we are not going to deep dive on the book. We just assume that you have an interest in that and you already read it. So we're going to focus on the principles coming from team topologies and how this helps us to guide, to build a platform that actually helps the organizations. Let's start, let's talk about platforms. One of the things that I learned early on is that it's really important to align on what we mean when we say platforms. Most of the times that we start talking about platforms, many people think about Kubernetes or like container. And while they are right, because Kubernetes literally, the definition is an open source platform that, that runs the containerized services, It is not just Kubernetes. So only having a Kubernetes cluster having in our organization is not gonna exactly help us what we want to, when we are thinking about platform, we need to go beyond the Kubernetes and like we need to think about maybe some commercial of the shelf products and infrastructure or some other services. We either build or get from outside. So we need to broaden our perspective when we are thinking about platform and talking a little bit above, not just on the tooling side. So for that, we need to align on this and that's why while it's gonna give us like what we mean when actually we say platforms. Yeah, platform is a loaded term. everybody means something else. And go and ask a Salesforce consultant in Ontario that they have a platform. And it's probably correct from a King's policy principles point of view. the platform is a thing that is existing with the sole purpose of these three, things. a platform needs to accelerate the flow of value. It simplifies things, it accelerates, the work that development teams, application teams are doing. It needs to reduce cognitive load for the people that are consuming the platform. So it needs to reduce the cognitive load in the whole, socio technical system. And last but not least, it needs to enable substantial autonomy of the teams that are consuming it. because we all want that. We want autonomous product teams that are able to deliver vast value. and a platform needs to fulfill all these three jobs. Again, it needs to accelerate flow value, it needs to reduce the cognitive load, and it needs to allow for substantial autonomy of the teams. Now, platform is an ambiguous term. Platform team is an even more ambiguous term. And a lot of people use it, not necessarily, Referring to the way, we use it in Team Topology's concept, context. from Team Topology's perspective, the platform team is a grouping of many teams. It is not necessarily one team. A lot of people say a platform team and they mean a department that happens to be responsible for some platform services. In Team Topology's, it is a grouping of teams, different team types. It could be streamlined teams, it could be complicated, subsystem teams, and they have the purpose to produce a product, a platform service that is consumable and easy, make it easy for, developers, people consuming it, let's say the team consuming it to deliver value fast. Before we dive in into the principles to achieve actually. we want to just a little, just in the words of cautious. So we're gonna, we don't have enough time to dive into all the principles, but, we are mainly, we decided to mainly talking about the value that we get out of these principles based on our experiences in the field with the different organizations and how we can actually, a little bit of guidance on how that you can also achieve the same thing. But what we actually want to do is to. Act like the great artists. We want you to, not steal them, but, I'm sorry. We want you to, Don't copy them, steal them. Don't copy them. Sorry. Yes. We don't want you to copy them as well, but we want you to steal with creativity. we are hoping that these principles and this discussion will inspire you to come up with your own principles that can, That can actually achieve what you are sent to achieve, what you are, where you want to go. So you'll, with that, these are the principles that we are going to go through. we're going to get the slides as well. We're going to publish them so you can also go through them, as on your time, time. And, we all have our own favorite principles among those things. So I will hand over to Val to start with his new favorite principle. Oh, sorry. Yes. Thank you. So the first principle we're gonna talk about is the team is the smallest unit of delivery, and that quite often is very much misunderstood by leaders. I see more and more leaders that are focused on developer productivity. Their focus on developer experience and that subtle change in language, forces them to look at individuals. And when you look at individuals, you're not necessarily achieving the best results. From a team topology perspective, the smallest units you need to deal with as a leader is the team. Productivity, impact, experience, all of these things should be measured on a team level. The value of your platform should be measured on the team level. Because if the team is the unit that delivers the value, delivers the product, produces product and delivers it to, to your end customer. So let's start by changing a little bit the language. Instead of speaking about developer productivity, let's speak about development productivity. Instead of speaking about developer experience, let's talk about development experience and let's start shifting the focus on the team. And the other principle is the platform reduces cognitive load and accelerates flow of value. So the first question that we need to answer is that we really need a platform. If you're thinking about the definition that Val gave us. platforms are basically here to be a catalyst of effects, efficiency and effectiveness. It should provide, I don't know, easy to use, tools, some clear guidelines and helping developers to reduce, reduce their cognitive load. If your platform fails to achieve these two key benefits, it may not just justify its existing. So a couple of years ago, we were working with this, organization and they formed a platform team. And they were really coming from a good place with good intentions. They identified some common services, and they wanted to take that load from their developers and provide some easy to use, off the shelf type services to them. Soon enough, they became a blocker because they were not really, following the good path. way of, providing services, they became this, blocker and bottleneck. So actually, if you look overall, instead of they are really reducing the cognitive load, they did the opposite. and they really didn't give the benefit that, they, they sent to achieve at the beginning. And just because that's your immense money on time, it doesn't mean that you should actually push for this. If you are really failing at these two key benefits, like providing them and maybe should start re evaluate and, maybe even decommission that platform and start from scratch. Yeah, to be or not to be, that's the biggest question to ask about platforms and, in Team Topology's sense, we speak about the thinnest viable platform, which is, what's the minimum implementation you need to do? quite often we see. product owners or teams trying to build magnificent castles and, something really big when the developer actually needs a skateboard or just a tent. so do or not try to, allow this kind of anti pattern to trick you into building a platform that actually becomes a botanic. Remember the three jobs that the platform have. It has, from the morphology's perspective, it needs to accelerate value. it needs to reduce the cognitive load. It needs to be easy to consume by, your developers. So how do you actually do that? cognitive load should be the main factor that drives your decision making. You need to focus again, the smallest unit is the key. So we're talking about a team of teams designs, not roles and responsibilities within a team. How do we distribute the work across multiple different teams, within the design that we are meeting in order to reduce the cognitive load in the system as a whole and accelerate the value in the whole system, this so sociotechnical system, what you see there on, on the images, one of the teams we were working with, building a very complex. platform that took, several dozens of teams to develop. And what on the wall is the domain driven design. This is event storming. the same technique that you apply in order to build sound microservices, sound cloud native designs, you can also apply it on your platforms. And it allows you to define good boundaries for different platform teams. Different teams that are going to build platform services to accelerate the value for the teams consuming the platforms. Another technique that we found, really useful to reduce the cognitive load is worldly mapping, because it allows you on one hand side to again, identify the different boundaries of services, looking at the value chain, that you would need to build, but it also allows you to make, build or buy decisions. So if something is available as a commodity, don't spend time and effort. and actually they, the whole, creativity. of one of your teams, go ahead and buy it. I have worked with an organization in the past that build their own service mesh. For Christ's sake, why? I, if it makes such a huge, differentiation for you and you build something that does not exist on the market, which is far on the left, okay, go ahead, invest and build it. But if you're building exactly what already exists, do yourself a favor. Just take it off the shelf. Have somebody configure it. And conceal it, or you could even conceal it as a service from the marketplace. So that going back to what Giles was talking about earlier. Should this platform exist? What's the minimum version of it that should exist? Don't try to build a magnificent castle if a tent or a caravan is good enough. And the other principle is treating the platforms as a product. This became super popular. It became like really, quite popular recently, and it is all right to be popular, actually, because it emphasized to, the importance of, the importance of applying the same level of attention and chair and strategic thinking, that, transcripting. That you would apply to a, any customer facing product applying the same attention, care, and strategic thinking into your platform. Basically, it puts your users in the center and design some pla design a platform that actually your user would like to use, would, would like to, come and use that they find their real platform and then very compelling. So by viewing the platform as a product we commit. We're coming to have a continuous improvement, like gathering the user feedback and iterating on features of the platform to have a better usability and effectiveness. So this mindset helps you to ensure that the platform remains relevant, valuable, and aligned with the needs of your users. and align with the teams that is actually get a benefit off the platform, which drives the actually satisfaction for that. Just like the any product that actually you are buying, like you are paying money. You should also think the same way for your platforms as well. No one is pushing for you to buy a product. No one is, you are not going to use any product that is not relevant to this technology or not making anything easy for you. So you should think the same. you should bring the same mindset to your platform development approach and making sure that actually your platform is, simplifying the needs for your end users, be, creating and creating an experience that actually based on their needs and Sounds like a very convoluted term. Let's pull it apart and look in practice what it means. True. Okay, so the real needs, the real customers. As I said that this platform as a product mindset puts the user, in the center and understand, what kind of needs that our users, what kind of things that our users need. So in order to do that, we need to really answer the question, the type of questions like, who is our customer? Like what? What do they need today? And what kind of things that they are trying to achieve and they are using our platform. So in this picture that you are seeing, there is a, what we call like user interview. So we are talking with the user and understanding, how they are today, interacting with the platform. What is their expectation from the platform? How they would like to, what kind of features or services that they would like to. See, so that we understand what is their motivation, what is the pain points, what kind of opportunities that we have to bring to the platform, so that we can actually address the user needs, so the actual user needs. And we don't really have one user of a platform, so different users have different needs. So probably needs to talk about different customer groups. And that was more about, different needs people may have. So, when we are building a platform, and when we are treating our platform as a product, we really, need to meet our users needs. And as you said that there might be not just one type of users. Our organization says. Multiple teams and different teams with different needs. So a couple of years ago we were working with this government agency and they want to build a platform to address their all developers and build something that all the developers can benefit off. And together we identified a couple of different personas, different developers, which was actually quite brilliant and enlightening for me as well. So during our interviews, during our engagements with the developers, we identified, one of these personas was, for example, what we can call default pet users. So there were some developers who would like to just consume the platform services, not really interested in how those services are made or how they can, I don't know, change stuff or bring new stuff. So they just want to consume this. services and like they want to follow some standard pets, but it is becomes quite famous. it's called like golden pets. They just want to follow this golden pads and bring their implications to the platform, consume the services and that's all. Like our platform needs to address this kind of developers needs. And there was this another persona, what we can call Adaptive users. So adaptive users are like, they're happy about what you provide, but they also want to tweak a little bit things to have a better fit for their own project. So you need to think about how you can build services that are configurable and address their needs. If you think about this golden path, for example, this type of persona is. Let's say they're happy with how, how they build their application on the platform, happy they have the containerization work, but they maybe want to, bring this, they want to tweak the testing bits because their use case requires something a little bit different, and you need to address, bring this flexibility and freedom to them so that they can actually, They can actually achieve what they need from your platform. So they, they were quite happy when actually we bring these services in a reusable components, a configurable way. They will say Oh, that's great. I can tweak the things that I need and I can get the things that I, there's off the shelf things that actually also. No, I need, and I can bring those things together and achieve my, achieve what I said to do. And that was on the other side of the, spectrum, what we can call these like innovative users. They were like always on the edge, following the new, new products or the new, frameworks coming in and they want to try these things to see if they want, if this is more, helpful for their projects, if it's going to make their life easier. So you need to have this kind of balance in your platform and address also give them enough flexible flexibility and freedom to, to make them this kind of experiments. And also set them a way to, contribute their learning to the platform back so that everybody can actually get benefit of what they learned, what they experimented and what they say. So when we say that we treat platform as a product, we must recognize that we have different type of users and what we, This one size fits all might not actually, wouldn't work, but it would never work. One size fits all in this, in this platform concept is not going to help us. So we have different teams with different needs and a successful implementation of platform can address all these, needs. And I can already imagine some of the questions in the chat. you keep talking about the team being the smallest unit and you keep referring to us focusing on the developers and talking to them. the team is still the smallest unit, but you need to talk to individual users, you need to talk to individual developers in order to understand different perspectives on the experience that is happening within the team. but don't forget that principle, it's really important. The team is the smallest unit. And, while you need to treat the platform as a product and go and talk to individual representatives of the team, what you want to focus on is how this developer freedom For how this development freedom, applies to the individual teams. And the way you do this, you don't build a platform for everyone. in marketing, they say, you should try to build a product for everyone. You build nothing for no one. so the same is valid for platforms. When you build a platform, identify the different groups of teams that are somehow similar, they may be working in the same domain, using the same technology stack. Take one of them as a representative and try to build with them. Because if you build something that works for them, most probably with some little tweaks here and there, it is going to work for everyone. Choose a team that you're going to serve and build the thinnest viable platform for them. Again, it could be as simple as a wiki page. What you see here is, from a few years ago, I think this is in the winter of 2018. We were working in Finland with an insurance organization and what in this room on the left table, the long table, you have a bunch of people and they are actually one streamlined team building an application and one enabling team. That is helping this streamline team to understand all of the architectural patterns and good practices they need to follow. and on the right hand side, on the table in the corner, you see the representatives of the platform team. So what is, what's happening there was that they worked for a period of time together, which in. team topology terms, we call collaboration. it's a close collaboration between two teams and the platform team built just the thinnest viable platform that this application team needed in order to run their application production, to develop it and deploy it and run it in production, nothing else. The product owner had a lot of drive, I could build this and that. And we asked them, don't do it. If you have an idea about a new platform service to build, go and ask the team. It's just there on the other table. Would they use it? What they actually need? would it make their life easier? Would it speed their development? And if yes, build it. If not, put it somewhere on the backlog and we can talk about it when somebody asks for it. another aspect of creating a platform as a product is if you think about it, real life, the more competition there is amongst products. The better those products become, and I'm not saying that Coke is better or Pepsi is better. It's definitely not good for your health, but the fact is, whenever you have products that, are in a competitive environment, they keep getting better and better. Think about Android and iPhones. they get better because of that competition to offer a better experience, more value to their users. You want something similar when it comes to platform services. some people call this. Make the platform optional, make your product use optional. some people will say, but no, we're in a secure environment. We cannot make it optional. That's fine. Think about making the service optional. So it still needs to be on that platform. Maybe somebody will come up with a better idea of how that service can be designed. Open up that opportunity for internal competition in a healthy way so that your platform services really fulfill the three jobs we talked about, making more independent and empowered, reducing the cognitive load and speeding up the flow of value. And don't forget, as we talked about, it's a little bit earlier with, the slide about worldly mapping. Everything in our life, and technology including, is evolving. It gets better and better, and eventually, things we considered innovation ten years ago, they are a commodity. Don't build a commodity. Figure out which platform services can be consumed from outside, and focus on building platform services that actually makes sense. because he said something really important and true about platforms. for your information, there's a lot more to platforms than people think. Platforms are like onions. Onions have layers. Platforms have layers too. And, I think, I'll go back to the slide that I presented earlier about the platform team. Remember, we said a platform team is actually a grouping of multiple different teams. You have Stream Aligned teams building their own service, their own platform service. Those platform teams, they have cognitive load, hey, they have their own needs. If you think about the generic representation of the technology stack in a company, in an organization, You would have, a three layered cake. Top layer being the applications, the middle layer being some platform services, which could be quite a lot. And you could have quite a lot of platform teams here. and then you have the infrastructure. But wait a second. why do we try to make the life of the StreamAlign product development teams, the teams building applications easier by exposing services and we don't do this for the developers of the platform? Developer of a platform is still a developer. Development experience needs to focus on reducing cognitive load, making things easier for the people building the platform as well. So platform engineering, I would argue, should focus also on the infrastructure layer. You should think about how can I make infrastructure services consumable, easy to, to identify, easy to consume, just like the way the platform, developers are trying to make the life of the application developers easy. So think about layers. It's not just one platform, it's multiple platforms. Each one, consumes the one from below all the way to your final customer. With when we are talking about like the multiple teams, having the communication between multiple teams can be hard. Thinking about like why we are building APIs between services to actually make the communications better and can also think the same, same logic with the, between the teams. So, we can find what about team topology is called team API about what the team is about, what they are working on, what kind of capabilities they are serving, what kind of, what kind of things, what kind of services they have in the road map, so that if one team would like to consume a service from the other team, they can actually, read the team API, understand what they're about and actually get their results. And so find their way without actually, really trying to increase the communication lines between the team. So team API has a really nice, template on the team topologies GitHub page. If you would like to, if you'd like to check it, it seems so simple, but it is quite powerful when actually these teams are getting team numbers are getting increased and increased. Since we are talking about teams and also mentioned about this, how platforms are evolved over time. we need to acknowledge that every product at the beginning, especially that they might have, they might be not so intuitive or not easy. Enough for the end users. So platform may come with their own this kind of complexities and learning curve. So we need to actually bridge the, bridge this gap between platform and it's end users. And that's where the enabling team concepts. comes into play. So their responsibility is to, enable the users to get the, to consume the platform services, leverage the platform services better and easier. And, while the enabling team is helping, enable the team, enable the development team, they also get more insights about how the development team is consuming the platform, how, what they can, what kind of services that they would need, what is their daily challenges, and they can also feed this into back to the platform team. How you can form an enabling team could vary, but It could be something like a couple of individuals from platform teams and working with the development teams. But the important thing is that, that collaboration should be time box. It shouldn't be like a, Commands and months long collaboration, because one is collaboration is expensive. That means these individuals are away from their platform services development, roles, but also that this development teams will start become more and more dependable to those individuals in enabling team. The aim of this team is to bring these development teams and make them self sufficient, enable them enough to consume the platform and, and, basically continue evolving the platform for the better based on their learning. Is there anything you want to add, Mel? no, I would jump to the next principle because we are, quite ahead in time. So the last principle we're going to talk about is that, Team topology is about evolution. It is, tracking the evolution of teams. It's not about labeling the teams. If you're just looking for labels, look in other places. Team topology is a verb. It is a continuous effort. And the easiest way for me to illustrate this is by making sourdough bread. We all love sourdough bread, or majority of people love sourdough bread. And if you ever tried to make sourdough, It's a continuous effort of perfection, every single time you try to make it better. In the beginning, it might be a very. Very different, very hard and not necessarily giving you the right results. So in topologies, applying topologies to your organization is the same thing. Just like you need bread every single day, you may need every single day to, to tackle the challenges of another team. Because you have a lot of teams, you have complex architectures that are developed with a big number of themes. you can't change things. One team at a time, you can't change things as a big bank. You need to take it as a continuous effort, looking at the patterns, looking at how you can make things better and better with what you're uncovering. So that was the last principle. And I'll leave you with this statement that we want to make with Johnson here. We want to advocate and argue that platform engineering is a culture of building platform services. That are focused on these four things. They're easy to consume. They reduce the cognitive load of those consuming them. They are continuously being involved. And they're economically viable. If you approach platform engineering like this, and borrow, like an artist, from all these principles that we shared, that come from the Team Topologies book and the community, You are going to succeed and you're going to be the next success story about how platform engineering changed, the future of an organization. So with this, we're going to leave you. Thank you for listening to us, can reach to us with, my email or LinkedIn, or you can also book time as well, if you want to discuss more. This, so thank you for that. Thank you everyone. Bye bye.