 So let me welcome you again at Developer Conference 2023 after a few years of a break. And it's really my pleasure to be opening this session of talks here at the Agilite Agility and Day and Leadership Track. Please feel free to scan the QR code. This is just my way of gathering your feedback during the talk. At the end, we want to spend some time also at the Q&A session. But also if you have anything else, feel free to raise during the talk and let's try to make it interactive for those here in presence. Unfortunately, those who are online can still use this QR code to start providing some questions for the Q&A session or I will change the IDN for the feedback if you would like to improve for the future of the talk, et cetera. With that being said, I will start with a very brief introduction. So I'm also one of those old-time red-headers since 2006 and actually it has been quite a few years since I had about technical talks here at the Developer Conference about security features, SCLinux, all the stuff which is pretty much used today for the containers you are most likely also using. But today I will have a non-technical talk and I'm really curious to see some feedback. If you're already here, I see one vote, why are you here? Or if you want to shout out what are expectations, anyone? Okay, that counts, anyone? So who's in a technical role or position? Just, oh, so a non-technical role or position? Is it a bit less? Okay, so this is really hard for me to guess what will be the target audience and I was actually expecting quite the opposite, right? Much less technical people and more non-technical roles. So I will try to adjust it, but again, feedback welcome even during and we will continuously keep improving it together. So I will start with really a lot of text but it's not so important. Is it more for those who want to review or watch it online? But what was the motivation? How I ended up in pretty much even proposing this kind of talk for the Developer Conference here today. So in 2019 I switched from engineering after 13 years to the IT and last few years the IT infrastructure organization was growing based on the complexity, teams were being merged, et cetera, et cetera and with the size there comes a lot of challenges and one of the challenges was really how can we get organized better internally to serve the needs of the internet customer? So looking at the audience I know we know it's 90 plus percent pretty much over here so you are the customers of all the internal business pieces of the internal infrastructure and we wanted to be, as you can see also here, seen as one. Not like we are selling duplicity, offering services some of them are even competing. It's really kind of hard after such a merging of the teams and bringing new people in the complexity in regards to the collaboration and communication was kind of becoming really, really complex and a burden. So there was an idea based on years ago when I read a book about the team topologies for those who are familiar give me thumbs up even hear the presence of I know how many people are already familiar, great and for those who don't really feel free to read the book it's easy to digest you can open it up anywhere and start reading or just go to the theorem team topologies for your inspiration and maybe learn something new and it was really the idea how can we approach this challenge to design our ecosystem in a better way and really this is the list of all the and even more items we wanted to at least try to address this is one of the slides I use one plus year ago really during the early introductions to the team so this is not something prepared just for today but just as create the flow of this talk on the left hand side you can see what we were already working on on adopting and pretty much saturating the ecosystem with the agile ways of working with the focus on the delivery and this is where there was a good fit from my perspective with the concepts and approach of team topologies also we were already working and moving towards adopting and growing the product management practices so this was also well aligned and what we haven't had yet and we are also working on really start focusing and build the foundations to bring us closer to the right hand side with the business and the leadership side of the equation and that's the voice of the customer like kind of approach and our goal really the focus on the satisfaction of the customers again for the technical for the TLDR version is on this slide but we will talk more in detail on the following slide this is a pretty much the agenda for today and really 10,000 foot kind of approach so our journey was from SIS where back then today where can we get where do we want to be and we use the team topologies again just as the one of the main communication languages as you will see it is also for inspiration because from my perspective and experience which was the most valuable part of it is really something you shouldn't be afraid you know just to start working with it and you will see some results pretty much soon I say so we started with a brief introduction of the team topologies then we had to create the map where we are what do we have today right that's the number two SIS state then of course you start seeing quite a lot of complexity as you will see on a few slides later so we need to start calibrating normalizing and pretty much making it readable because it will you know shock you how complex is your work around you then we introduce something which you will see zoom out to simplify the high level complexity into something which is again possible cognitively just to assess and analyze what do we have and start moving really toward the 2B state because this is why we are doing it right we are not doing it just to know where we are or we want to improve and get better at something and the last part is really start executing and it may be not on this slide but later you will see GFN which stands for good enough for now this is something which I really recommend don't try to make it perfect and avoid making any steps or any changes because it will be never perfect really get it into the state where you feel is good enough to get you moving forward make one step forward but quickly and iteratively assess accept the feedback adjust and in the cycles keep moving this is where the alignment with these sessions or these tracks with the agility comes into the play one of the important part that my recommendation was pretty much and was also to do the due diligence are we really looking and thinking in the right way is it going to help us and this is just for those and I might also help the technical audience here how to do the due diligence I had very good experience with the tools like the Tough Forks radar this is in the upper right corner this is radar where they are evaluating the trends, the technologies and giving recommendations in the form adopt, hold or avoid etc so this is really something important if you haven't heard about it and it gave us kind of the reassurance yes this idea is really promising and should give us some valuable results as you can see since May 2020 they were advocating for adopting the product management practices for the internal platforms which was exactly our case also from the engineering products platform for the engineering products this was confirmed in the several other evaluations but with one important item which I wanted to mention to you to hold with the miscellaneous platform teams that means don't overdo it don't put platform everywhere because you just have an idea or now it's trendy to call everything platform now really be careful because this leads to kind of lack of quality of those platforms where you are missing the understanding what's the purpose, why is it here so don't put platform and try to you know kind of get the platform onto everything so be careful and really pay attention whether it's and what type of the platform are you looking after and when I was preparing the slides for the talk this is in the lower right hand side adopt is few years a few days old information that still they are recommending to continue adopting and applying the product management to the internal platform so this is something which can help you to get the buying from your management or leadership team and that's why I told is important and also to confirm that your idea is going to be successful and another important or from my side recommended analyst here, Gartner is also something which confirmed that yes this is something where the industry is moving now we are starting on this slide already with what is the platform as a product the TT stands for the team topologies and this is really the screenshot from all the materials you can get online this is also what I forgot to mention the objective for today is not to go into the details we don't have enough time but I just wanted to get you started or feel free to find me I will be here till Sunday and we can talk about it more in detail but this is something which I'm expecting you will have time here to search online I can recommend some places where to get to know also the team topologies has quite nice web pages and a lot of resources for you to self study and pretty much get you up and running so what's the platform as a product so platform is a curated experience for the engineer this is how they define it which goes to the engineers so you here if I understood correctly as in technical guys are those customers and this is what was also our case we wanted to get closer provide higher value to the internal customer it's not going to be the next day but this is the long-term pursuit and platform as a product so what does it stand for you to treat the platform as a product for volunteer internal customers and the volunteer is really important it's not something which you will be forcing this is the only platform you have to do it exactly in only this way this wouldn't be aligned also with a spirit of this conference open source but really it should be guiding you by the customer focus to make sure it's reliable it's usable for the customers being the internal engineers or communities et cetera and also down here I listed few bullet points which is really important for you to start thinking already to help you to define well your platform what are the behaviors platforms we will get more in details about this later what is the purpose of the platform this is the most critical and this is also something which was misused by the concept of the miscellaneous unclear platforms and the metrics if you don't know where you are like GPS coordinates et cetera it doesn't get you too far so the metrics to see the progress if you are moving if the anticipated results are getting towards you that's it this is another lot of loaded of information there's no intention to teach you today to the entopologies over here I will just very briefly mention just quick guide or quick sheet kind of information what are the bits and pieces we started working on and very briefly on board pretty much everyone we need it from the management SME is senior engineer et cetera so the team topologies on the right hand side is using this kind of I call it like visual language which depicts the team interactions the three team interactions and team types for a fundamental team types and one which is at the very top undefined team type and this is what you will find most often at the very beginning when it's unclear what should be the what is it where should be positioned but over the time as you start discussing you will figure it out oh actually this team fits the concept of the streamline team or we would like to evolve it into the enabling team et cetera for those who read the team topologies book or some articles it will be maybe something you are aware already and the convey slow or how to pronounce it and over here I will mention it again later because this was one of the most valuable part and there is a concept where you reverse it so instead of designing the technology design and technology technical architecture around the organizational structure you try to do the very opposite you try and this was also our challenge or one of the aspiration to improve how we are organized internally not vice versa but to match the technical architecture and the technical needs for the internal platforms and it was also something which I would focus or recommend to focus on to try to focus on the technical needs first and then organize the people avoiding to get into who's reporting to who how we are pretty much in the world chart organized today and et cetera so one of the most important parts for team types streamline enabling complicated platform you can revisit the definitions later this is not so important for today for today what's the most important is the very bottom one the platform team because this is what we'll be focusing on and the concept of the streamline team also because the platform team's purpose as you can see is to provide service and the company product to the internal most likely or most targetedly the streamline teams were focused on the continuous value delivery and to focus on pretty much not being interrupted or spending too much unnecessary time on figuring out on their own what do they need, how to achieve it that's the power for the platform team to address by providing the what's shown here as XAAS the triangle which is something as a service and this is the basic on the main concept also within the context of this talk platform teams offering something as a service to the streamline teams and others within the organization any questions at this point because it's familiar maybe to me but there is a lot information okay so let's jump right into the example to get you started as I explained on the previous slide basic visual kind of symbols at the very bottom you can see the platform team this is the team which is offering a service what kind of services are your teams using, anyone? Feel free to shout out no flag, okay, anything else? You're silent, I know it's morning confidential, okay, but your teams are using services which are maintained and provided by some other teams, right? And this was the main idea this is why I wanted to re-fan size is now that we wanted to focus on adopting the product management practices how to run the platforms so not just any other team because easily just shift towards we do everything, right? But really to understand the concept of the self-service which is X as a service kind of goal, right? So on this picture you can see in the middle of the yellow streamline teams look at it in our case mostly running using the scrum but pretty much it can be engineering team it can be some front-end team or another development team pretty much dealing with the end-to-end delivery but also you can see here the kind of interactions at the beginning the first two teams at the top the yellow one need to collaborate this is what it means also towards the later stages of the delivery the very top one streamline team needs to facilitate and get some help from the enabling team the purpose of the enabling team is to help to adopt something new which the new team doesn't have the streamline team doesn't have yet but their goal is to teach them how to do it to make them out on the most in the contract of something which we are not going to be using very often here but it's a complicated subsystem team and a complicated subsystem team is the type of the team where there is some really high-level expertise required and it's better to let the team to do it for you instead of spending a lot of effort and time to show you and to teach you how to do it on your own and they will come and get the job done for you at every bottom again this is the platform team serving the services and that's it but let's move on because these diagrams will get into the real situation this is something very easy cool, so after a couple of weeks so we introduce what is the streamline team what is the platform, et cetera we were starting to map across the whole organization so what do we have the assistate today and this is one of the snapshots you know the, it was even bigger let me put it this way but I wanted to something that will fit the screen and on the mirror which has a good integration with this kind of visual diagrams for the team topologies, by the way and this is how we started mapping so different teams started, so what do we do who do we serve, who do we interact with what interactions do we have so really mapping out the assistate why I'm showing you it will get easily depending on the size and the complexity of the environment into something like this which is really pretty much even impossible for one person to understand completely and that's why also we wanted to start calibrating do we see some patterns do we see something we are pretty much already mapping duplicity and et cetera so this is where we spend a lot of time you know to calibrate adjust and repeat until we again understood yes this is good enough for now and we are ready to move forward when we felt start move ready that is polished enough after the calibrations and adjustments we've introduced the concept of something which is the internal platform topology so pretty much just encapsulated this is the red arrow so instead of looking at the platform we just consisted or build off another internal platforms or stream lines and et cetera you just don't need this detail anymore you just hide it and you just represent it as one platform on the right hand side is it showing, no over here so this helps you to visually hide the unnecessary details again not to get distracted by something you don't need to solve at this point but this is helping you to understand and get as enough as possible clarity about what is the purpose of these platforms who are we interacting with facilitating, collaborating, et cetera and especially this is the point where we started focusing on mapping the external teams the external, internal customers external from our perspective as a organization but still internal within Red Hat so this is how we oversimplified but again by zooming out and merging those platforms into one bigger picture so this is the concept I wanted to show you because again depending on the complexity and size of the environment most likely it will also end up with something like this and this is again it's not important the content the specific names, et cetera but just again to give you the feel and the idea what was likely you will be ending up with also you can see that we started or needed or felt like we need to start making or adding more information like those red bubbles like where are the gaps, where are the challenges what works for us already today but again this was still part of mapping and getting good enough clarity as one of the first half of the process to understand and refine the internal platform you so this is how do we see ourselves internally and if you remember at the very top of our goals to be seen as one team externally so we will hide it so this is how we also mapped out the external perspective and their needs we need to spend a lot of time and this was pretty much the biggest effort to understand the external customers we needed to start adding the other two like the spreadsheets a lot of discussions, dialogues but really who are the customers to map them because it's not like just the names but we introduced some sort of persona mapping are the developers, are the seasoned means are there in some marketing teams are there you call it out you name it, right, really to represent them and to normalize them into something which will be again easier to work with moving forward when we list it and this is one of the bullet points so what do we own today are we going to offer it, you know, till when, right does it still make sense but again, repeat until you feel it's good enough for now to start you moving forward and this is something which we more or less as a Polish version ended up so roughly 10, 10 plus teams in regards to the streamline teams who were focusing on the continuous value delivery to the customers but from the customer perspective they don't need to be visible they are encapsulated by the platforms you can see here that we also keeping in mind Convoy's law and the inverse maneuver of Convoy pretty much understood that oh, actually we are also layering the platform internally already so all of this about is what we'll be seeing as one huge platform from the customer perspective but internally we had some core platform you can understand like network services if you need to reg and stack and get everything in place and the top of you need some, you know services also at the top or in the middle I would call it between at the very top you can understand that could be like the cloud infrastructure for you the abstraction is really at the higher levels but also closer to the real customers and also this is not intended to be precise but to get you the feel but it's quite let's say good enough complexity how we really ended up pretty much simplifying all the completing and you remember the couple slides down the huge bubbles of different teams different services, et cetera we also ended up with quite a few teams which are called in the purple kind of verticals and these are the enabling teams these can be either teams of someone specialized or teams enabling mostly through the facilitating like the delivery functions or another shared functions within the organization and also we needed some of the specialized functions which really are the complicated subsystem teams to be closely either present within the three platforms that they are layered from the financial to the very top platform level or even separately and serving the whole organization any questions at this point? Communicate your three different stations this is more from the technical perspective you look at as I mentioned the network right first it doesn't make sense to serve any cloud services if they are not connected right so this is the network layer and it's being used even internally so the platform of Bao is using the services offered within that large platform for their own needs so this is for example this triangle so use Can you indicate as a service? Yes, yes and this is again oversimplified if this is like the blueprint to adopt to present and now we will get to the point like how to execute the change it's not overnight and this is also what the team topologies kind of addresses or helps you to guide through they are providing some specific patterns again depending on your field of the technology domain how to evolve the team so most likely even today when you have just streamlined teams who are serving the services for their own how to decouple it how to know what should become or turn into the platform and what should be separated just for supporting the flow of the delivery not being interrupted by some you know delays or some specialized functions and to move and try to move towards the self-service kind of mentality where you're enabling the internal customers to serve themselves to their needs while you are maintaining the internal product for them at a high quality does it answer your question? It's complicated, yes that's why I also said this this is something which I drew intentionally not really giving the names because it wouldn't make sense this is really depending on the internal context but from the customer perspective they're seeing external to the infrastructure platform they are experiencing just a couple you know services for them again I'm not specifying there are more but it will be again hard to read but this is just to give you an idea that you will define these are the internal platform serving the internal but this is like two encapsulation levels here we are looking at but also we have a lot of externally facing services because this is our primary objective, right? Cool, any other questions? Yes? So the question is how to handle the dependencies between the teams and the platformers, right? And this is your question from the customer external perspective or internal because it will be the same kind of okay, okay so in that case this is exactly where also from the perspective of team topologies the product kind of mindset and the practices come in place how do you release something which are the cross dependencies and this is where the collaboration the communication is the key and this was also one of the anticipated benefits we wanted or desired to get out of this approach to line better so try to remove these unnecessary dependencies to try to avoid or mitigate them where that doesn't make sense and bring them closer for the more effective so these dependencies or the circle or the circle of the dependencies they'll be kind of not even avoided but through the collaboration close collaboration communication minimized you didn't answer the question we will need to look at the specific technical but this is actually the concept of the convoys law where either the organization is or the software architecture is going to mimic the organizational structure but we wanted to do it opposite so when you try to design the teams in a way that fits better the technology architecture this kind of goes away or you are iteratively moving towards removing this and minimizing this back but to be honest it's impossible to avoid it completely, right? So it will still be there okay, any other questions? Starting with the Q&A only, okay so I will go very briefly we have five last minutes definition and the formation of the new teams when you are down with your architecture how to start executing, right? And this is the most important part also from my perspective an experience to focus on the teams not on the individuals, right? These are very recommendations and also what I haven't mentioned is that it's important to try to avoid getting into the people discussions till the very last moment possible and to focus on your design and the architecture first because this will be much easier when you are clear and you see the benefits why it's better to do design this internal architecture this way and just get together what do we need? Also what's important clarity of the roles responsibilities and the measurements so you know where you are at and if you are moving in the right direction because this won't be possible to do everything at the one time also long list of observed benefits you will get the slides also we've been recording so you can get through it later we already mentioned many of those which let me have a look at it we haven't mentioned very quickly from my experience to adopt and understand it might be overwhelming for the half an hour talk but definitely when you have more time to look at it it's easy to get you started and introduce to your teams also I mentioned one of the few bullet points communication and collaboration really improved significantly we've already had some experience with the product management it was also one of the goals as we had mixed environment some were moving or operating more in the project management like ways some were already working with the product management practices, et cetera but all of them had the kind of desire and it was also important to have the commitment from the leadership and the organizational kind of decision to work within the agile ways of working or modern ways of working as we can call it, et cetera and the visual language is what I like also created this presentation within the mirror so the mirror was a very, very helpful tools a lot of other noteworthy substances when I was kind of or we were moving towards the end of pretty much getting ready to start executing the change the unfix was very important also for me so if you want to go further even maybe less technical the unfix is something I would recommend or to motivate you to have a look at also if you are in a position facing a lot of project management the PMI Agile Discipline Toolkit really is something I have very good experience working with if you are in the more agile scrum environments, crum at scale and also the Open Practice Library is another great resource of a knowledge and the knowledge and the knowledge management is something I will end this slide with because this is critical not just technical but really the knowledge and the experience in general and have a good knowledge management strategy ready to support the folks transitioning into new responsibilities where you need to grow the new skills, et cetera with that being said thank you very much feel free to provide a question I will check yours or for those online questions and answers last few minutes which kind of metrics do you use that are understood by the management? metrics? yeah so pretty much yes I can answer very briefly you remember those three platforms so this is where I like the unfix the concept of the turf to make sure these are the areas of the closest as most interactive collaboration but again try to reduce the complexity and the size as much as possible and that's why I like also the team-first approach not to have 10, 15 people like teams but really try to have smaller teams which are much more flexible and if the type of the work allows it to be autonomous any other questions? yeah there are questions read it out results inspiration any other questions I don't see I just see one there I see one six six? come on what's going on? should I read it out? yes please what advice would you give to someone to build a platform team today? just get started really don't avoid it and focus on really what do you have today and especially focus on the customers because this is why you are here you are here to serve the internal customers or even external customers any other question? it's definitely helpful if you have at least someone who is knowledgeable and skilled and this is also what I meant by the knowledge management that if you don't have the experience you might struggle and I would really recommend also to spend on building the foundations being various agile kind of ways of working the product management etc question? so there was a comment that without the product manager it's really hard and this is really where you are here to focus on the customer and the product management should I'm not saying it always but should help you to be better at it and you need to grow the skills it's not just one-man show definitely and also from the product management perspective focus on the value what's valuable for the customer not for you because this is very common for the technical people and organization they focus on what's easy or what they like to do but it might not be the best for the customer this is where the product manager and someone really skilled and good at it can help you to pretty much get better any other questions? I know we are two minutes over the time just that's a complicated question I'm not going to take it probably this time thank you be free to stop by so thank you very much again and have a great rest of the conference