 Okay for our last session of the day we have an awesome panel of platform luminaries led by the amazing Courtney and Courtney will then introduce everybody else so take it away Courtney. So thanks for sticking around it's been a very long productive fantastic day filled with loads of information we've very much seen the birth of the first platform engineering day so congratulations to everybody who has put this on this is fantastic. We're going to be talking about how to navigate the path to platform engineering success everybody is doing this but we're seeing the birth of a movement here today and so we're going to kind of talk about the different things that people need to do and consider and how they can actually get their platform adopted and be successful in doing this so that in the future we're not discussing whether platform engineering is dead rather we're discussing how platform engineering has changed to the way that we're practicing and morphing into a new thing so without further ado my name is Courtney Nickerson I work for a company called Coop Shop and I'm going to let my lovely panelists introduce themselves. William? William Ritzel? Sousa? Hello folks my name is Aparna Subramanian I'm director of production engineering and I work for Shopify. Hi I'm Abby Bingser and I work for Centasso and I'm also a co-chair of the platforms working group for the CNCF. Hello I'm Areti Pano and I'm working for SAP. Fantastic so obviously you guys have been here all day we've heard loads of different definitions of what platform engineering is what platform is are these two things the same Abby why don't you kick us off with this one what do you think? I think platforms are clearly interfaces if you're here in the morning no I think platform engineering is engineering I think there was a fantastic quote earlier in the day I think by Samantha someone about how platform engineering is a software exercise yes it relies on reliability and operations but it's a software exercise to provide value to your business and that's what we're seeing with the platform as a product conversations going on all day as well as the the different implementations which value kind of day-to-operations and fleet management and APIs and all these things that we've been doing for software for years. And William I know you were very passionate about your definition and the one that you like platform engineering how do you like what's your favorite definition of it? My favorite definition it's an empathy driven and socio-technical exercise where the features and the of the platform are not necessarily at the at the core of the platform where but the interaction between the developers the stakeholders the users the platform engineers and the ultimate outcome of the platform is what is most important so that's for me a platform. Anything to add? I would like to add that a platform can be as thin and lightweight as you want or it can be as complex and heavy as your use case demands it and I'll also say that as a user of in a public clouds GCP at Shopify our platform actually evolves and marvels as the capabilities of GCP evolves so yeah I think it's a platform as a living breathing thing. And continuing with that Aparna do you think everybody needs a platform? That's a great question I mean it depends again on your use case and the scope and the complexity that you're trying to solve if it's you know two people and you know what your if your scaling plans aren't that big you know maybe you don't need a platform maybe your platform is a set of best practices on how to use certain things but if you want more repeatable control if you want more simplified management if you want predictability if you want to scale things if you want fewer sort of like you know run books and like last-minute heroics then I definitely think a platform is a good idea. And what are some of the cultural drivers because Arreti I know you service what did you tell me 30,000 developers? I cannot hear you. So you service 30,000 developers something like that as a platform engineer and product owner so what are some of the cultural reasons that people need to be considering when they're doing platform? I think many of the teams already had some layer of a platform I think it comes to the question whether we need to centralize that platform because one way or another everything had something and that's something you need first to evaluate what is the status quo what everybody is using and then try to decide what needs are covered by what teams already have because you it's not one customer there you have very diverse setups and you need to find out what all of them what are the partners that they are actually serving and then try to come up with a best compromise because the platform in the end is a compromise you can have one platform that serves every team so you have to find the best minimum viable product. William you work with a lot of customers right and consulting them so how do you see the the whole cultural aspect of platforms and how do you help people with those situations? That's there is no there is no cookie cutter solution for our situation that I mean there are several customers which do not understand the benefit of platform engineering other customers that do need to understand want to understand the benefit of platform engineering but they are scared because they can't they can't calculate an ROI I was speaking with Ebi and there are some other customers which I always ask what is the what is your ultimate goal what is the business value are you reaching your business value are you is there impediment in reaching that business value if the answer is yes to the last one then okay let's see how we can move forward and what are are you working into silos across developers or operation folks can is there already an initiative that is self self initiated by the developers normally to build something to speed up the business value or to the order development and and I approach it as a consequence to those answers. Of course I think it's a really interesting combination between what you said already and what you said William about platforms versus platform engineering because the the conversation you said here was already was that everybody has a platform it's just to what degree they're investing in it to how customized it is across the organization and how standard it is and you mentioned the conversation on whether or not people believed in platform engineering William and I think that fits really well with this maturity model that Nikki just blew us out of the water with on the last talk that we start at the provisional level not to say that you are insufficient if you are at provisional but to really call out the fact that I would argue every person in this organization in this room and in any technology organization is using a provisional platform you may not be investing in platform engineering as a practice and with like kind of concrete outcomes but you're using a platform when you need the more centralized and when you need to invest in the kind of built in security and those kinds of things that's when you need to invest in platform engineering as a practice as socio-technical practice and so I think that's an interesting conversation between platforms versus platform engineering and talking a little bit about getting buy-in from people a partner you also work a lot with getting buy-in and helping platform teams advocate for themselves. Yeah definitely I mean I think of it as more of a partnership than buy-in right because if you're really collaborating with your application development teams and you're helping them solve their problems then the buy-in part becomes you know less of a hurdle you're actually co-collaborators and you're solving the problem and I've also seen this pattern where the solution is actually created by the application development team and then as a platform team you work with them you standardize them you know you may be built in built in security and other things and then you sort of create a standardized solution for the rest of the company so yeah that's how I would approach it and we approach it at Shopify is it's like what are you solving for the application development team what are you solving for the company and for the business. Awesome so there's a lot and we've heard all day today how to put your client front and center user who are they and what things need to be considered but you go through all that process and the question begs if you build it will they actually come and when they do will they actually use it so who wants to take that one on first I want all of you to speak to this because I think it is the the question of the day. Yes I think everybody needs to answer this because everybody has a very different perspective of if you they build it first of all they need to know about it so depending on how big your organization is you have to find the right way the right channels to advertise it so just because you have a great platform doesn't mean that people know about it if it's not advertised the right way the other thing is that it needs to be interesting and it's to solve a problem that they actually have if everybody has something that is working and then you say here's our new platform nobody's gonna come because they doesn't solve anything new and I think the third thing is at the end management support if the platform is interesting and it does solve a problem to allocate the time to move to the platform because that doesn't necessarily come free and I think that blends very well with developer experience that the requirements come from developers so if there are no requirements no need for it they won't come. Absolutely next we're going down the line I'll go from maybe I agree with everything you said so I could just repeat it all but I'll come from a different angle and say also whether or not they need to go to the platform so I think we often try and deliver a platform and people will come because it's so interesting but do they actually even have to realize they're using the platform can you build things in in a way that is kind of transparent to them I learned this lesson in the very hard way after rolling out CI CD templates to an organization of sort of 30 to 40 services so sort of pretty small scale and compares into a lot of the organizations here and then we want to change how we delivered the software to want to change from a push-based kubectl apply kind of push to a GitOps pull well that involved changing all of those pipelines and all of those pipeline templates that had been so nicely rolled out had all changed because now they were owned in the different code bases and when we were like but this is great you have better disaster recovery and it's more flexible and you'll love GitOps everyone's like I don't care and so what we realized is we needed to roll out not only to those pipelines ourselves manually and give bits to them we also had to roll out in a way that gave us as a centralized team more ownership over improving those over time because the teams didn't actually care they just wanted their stuff in production and so yeah I think sometimes we worry so much about them about users wanting to come to our platform we forget that our platform in some ways could be transparent to them and that might be the best possible solution definitely agree that migration is probably the hardest aspect of adding new features to a platform creating new platform features is actually the easy part and how how you engage with your internal customers how you bring them along how you make that process of like migration and onboarding to this new cool feature that you've built in the platform that's the hard part I'll just say that don't think of your platform users even if they are within your same company as like the captive audience right because I mean your the feature has to justify its value just like a product in the market for them to be able to like adopt it and appreciate the value and on board that new feature that you built I was I would say if if your quest if you have built a platform and then your question is now I have to get users to come on I think you shouldn't have built the platform the platform in first place so the platform is a response to a need to an agreement that you have with the developers or the developers that initiated this thing building this thing and the developer themselves or the platform team will get first we will get more developers to onboard through a developing internal developer relationship program or through just word of mouth so the platform it's so the answer is if the platform is already there you they are not gonna come they're gonna come if the platform is built in the process with them already yeah I think that's a huge huge thing that we need to talk about as well is how do you include people to make sure that they're on that journey with you so what are some steps that you've taken out at the for example to include people to make sure that they're on that on that journey with you as you built I think there was a presentation before about UX so and product management it's first to have interviews conversations with end users to try to see what they are actually doing not what they say they are doing but it was in the UX presentation it's actually letting them go through a system also what are you doing today and not what you think you're doing but what you're actually clicking on today to get something done and when you see what they're actually doing when they get stuck where's the friction then you start having what is the need and then you get to see the opportunities that might happen which might be we just need to write some documentation here we just need to improve the error message and nobody needs a platform so it comes from the product problem and facing it like this then it becomes much easier to decide also what to build and whether you need to build so this is how we are actually doing it or we try to do it at least abby anything to add I'm terrible going after already she says all the smart things but you have nicer stories no I think bringing people on the journey is as you say meeting them where they are I think again I'll maybe be contrary to what some people think but sometimes I think the interfaces we use should actually be the ones we currently use so it's not you know everybody's like oh I want to get away from ticketing platforms oh I want to create these brand new amazing web portals or CLI's and things but that's changing user behavior and if you're not gonna 10x 100x the value to that user of what they're gonna get from this brand new product that we already know we're not supposed to build completely before they we bring it to them because then they'll never come to it then we're unlikely to meet that and we've changed their behavior for not a ton of user benefit so I think where I've seen some success is when we actually put automation or better experiences behind the interfaces we're already using so they're starting to get value quickly and then they're more inclined to change their behavior towards whatever new interfaces you want to introduce because they are you've already won their interest right? You've given them some value already. Yeah I'd say that as a platform team you know you probably already own a set of applications or services that you own and you run you know be it like an inventory management system fleet management system whatever use those to actually dog food the platform that you're building right and I think that goes a long way in being able to experience those issues firsthand and gaining the trust of the development teams. Anything to add William? You want to jump in? I am very sorry I didn't understand the question. Okay we'll skip new question for you. What types of things should they be? You start there now. Yeah yeah What types of things should it so we're bringing the customer along with us we're assuming that they're always right but what types of things should we be measuring as we're looking to the adoption of people adopting our platform to ensure that we're on a path of success? I love what the speakers before us said if you can't measure it it didn't exist so what should we meet what should we be measuring everything what should we care about what brings us what brings business value forward what satisfies this business requirements we need to we need to be able to measure productivity we need to be able to measure satisfaction of the of the of the users we need to have a constant feedback of the users these are all measurements that might be numbers might be heat maps or however you want them but we need to be able to measure from the users did we need to build a roadmap did we meet that roadmap did we meet that deadline and did we satisfy that the requirement of the developer or the stakeholder of the platform that's what I think. Aparna? Yeah it's definitely a combination of like you know measuring all of the SLOs the KPIs and also what I already mentioned about like also doing like user interviews because you know this is only like part of what you can measure and what you can understand but there's also the other aspect of like that true partnership working with the customer your users understanding their pain points so I think they go hand-in-hand. I guess the only thing I'd say to that is measure everything so you can track it and change it but also understand it's okay to have measurements be short-term value so good heart's law what you measure will change behavior sometimes it makes sense to have a measurement for a period of time to track an improvement you want to introduce but a long-term version of that measurement may actually swing the behavior in a negative way and so I think yeah think about tracking what you're trying to introduce without feeling like it has to then be something you measure on a dashboard for the rest of your your career. And when I think this is a very interesting question and it's very very hard to measure when somebody says what are you measuring I I can't think because it's a very complicated thing in the sense that platforms we I'm product owner of the CI CD setup so people are not coming back to set up pipelines daily so it's not growth and they have set up one pipeline they have not set up a second one is that because it was not good enough or because it just had one service to build a pipeline on so when it comes to measurement you mostly have indicators so you try to find two three indicators that make sense and see how they're moving especially in the beginning because growth in the sense and social finite market you're not having the world you have 20 development teams so you have a very limited market and it's not really growth in this case so it's kind of looking into the indicators seeing what makes sense switch and then see if it's word of mouth in the end and qualitative data because referral is mostly what gets the platform going absolutely and just a side question so as your platform matures you kind of identify those indicators do those indicators change over time do you need to change the what what is that you're measuring or do you stick to the same measurements and indicators how to what does that maturity look like as time goes on I think also you're doing it for the usage how how is your platform used but you need to combine it with it's not used because it's not easy it's not used because it's not necessary it's not used because because because so I think the indicators with the questions change in combination I can't think of a good example to do that but I think it's balancing this too okay a partner add no I'll just maybe give an example that maybe if you're using rolling out a new feature measuring daily active users is great right because this is the first week and okay you want to know how many teams are even like trying it out but quickly that that doesn't become a very relevant metric to use and then it becomes like okay how many times this thing actually works what's the deployment time are we improving the deployment time are we shortening it are we actually helping to the productivity so I think it that's probably an example of a metric that would change over time anything else William I would say that because the numbers show what we want to see doesn't mean that it's a good thing so what we said measurement measuring so because people are involved I like I like the term evaluating more than measuring so when we are measuring we're measuring active users we are measuring very precise numbers when we are evaluating we are doing that but we're also associating those those numbers to the experience of the user is the developer sticking around because it is doing a lot of work or is the developer sticking around because he can get the work done or she can get the work done and it's trying it keeps trying to get it done so we need to so the number would be the same in both cases but the evaluation would be that they medically opposite in then in both cases so we need to have a way to measure the numbers but we need also to have a way to evaluate the experience and associate it to those numbers now I think you draw on a very important point which is is about the human interactions the human relationships and how people are actually relating to something as human beings because it's their day-to-day tool but they are day-to-day humans also and so the words that we're using and how we're defining these are using evaluation instead of measurement for certain aspects or promises and stuff as as a way to get people involved in the process are super important things to keep in mind we're getting close to time to wrap up so I think we should really take advantage of the fact that we have pros and ask for some pro tips so give me your best pro tip for navigating this whole process to make sure that you find success who wants to go first I'll say that as platform teams it's often tempting to put yourself which is the platform team first ahead of the application team and ahead of the company so I think it's just important to be mindful that you know the company or your business comes first and then your customers and then yourself as difficult as it may be to like sort of have that identity value what is my team doing sort of justification as platform teams it's always the best thing to put the company ahead of ourselves yeah I think I add in that it's important to realize that often we're in the position as platform engineers to keep the lights on we're doing a lot of the BAE work around an organization and it's hard to do a rewrite of something as foundational as a platform and so what we need to be looking for is ways to take the value we already have in our organization and make sure that we expose that in a more self-service way in a more operationally kind of fleet managed way and and make sure that we're building in those business requirements to make that more manageable and maintainable for our business and more valuable for our business without feeling like we need to pull in whatever brand-new tool has just come out and completely rewrite every piece of technology in our organization already William which one William William go for it I would say that the platform is nothing more than a digital screwdriver it's a tool it's something it doesn't mean to an end or a mean to multiple ends but it's just there to satisfy a goal so and that's how it should be seen and used and eventually dismissed when is is not relevant anymore and just move on to the next platform so three days treated more as that to satisfy the need of its users rather than to satisfy the ego of its creators and I think because the the people we built for our colleagues in the end so it has to do with the relationship of trust these are not random people that you will never see around but these are people you're actually sitting in the same offices with so when you have this you have to have this relationship of trust with them so that they are using something within the company and usually in the companies people talk to each other so having this relationship with the people you're building for I think it's it's a good thing and platform teams are in a privileged position to work with their end users in the same office absolutely awesome awesome insights just to wrap up a bit I know all of you are involved in different types of groups excuse me and create different resources have different communities that you're involved in we've got a list up here so that we can help everybody get involved but talk a little bit about the different groups you're involved in apart now why don't you go first yeah we'd love for more end users to join the CNCF end user developer experience thing you know in the CNCF Farlands end user means you're not selling or monetizing any of these cloud native technologies but you're using it as a user so we have the developer experience thing that meets every other Thursday and we'd love for more participants to join us and discuss the topic of all things platform and operationalizing a platform Abby yeah I think you've heard today a bit about the CNCF platforms working group underneath the tag app delivery so there's some fantastic work being done and there's a booth within the sponsor hall later where there's gonna be some fantastic conversations around how we do platform as a product in real life today so again if you're an end user that's where there's a lot of value to have those conversations and share your stories so yeah please get involved and come find us in the CNCF slack and elsewhere and I'm not in any community though but I saw now there's a platform as a product research group which I would like to be involved in and I've put in there some books that everybody wants some very basic product management skills just to see what five things to do are I've put there some resources that anybody can just live through and get an idea William yes I have recently joined the the tag app delivery work platform was working group I am I am also part of the tag environmental sustainability and please join us in either or the working group yes that's that's a that's pretty much all but it's great because like William does this all the time and he's just joined so everyone's can join it doesn't matter how advanced of us you are or not I join it I believe I believe the least advanced or whatever advanced means you are the more welcome you should be a fresher look at things it's always better from very very strong leaders they might if they're really leaders they are gonna get suggestions for somebody that just came in and sees things from another perspective so you don't need to be advanced in anything to join something absolutely something very concrete you can do this week is we're having morning coffees I know it's 715 in the morning I'm so sorry but if you're awake Le Ballon which is the hotel just across the street is hosting we have some coffees being hosted in the mornings from Sintasso my company Gitpod and Crumbware so some croissants and coffees with chats about platform engineering so please come and meet the community share your stories and it's a great way to get to know people you also do online coffee lunch session that's London yeah yeah come hang out it's online UTC it's available to a lot of Europeans then so yeah some tons of places to get involved so thank you very much I'm sure there are questions so any questions at all we've probably got time for one or two yeah just a quick sort of question here a lot of the responses of sort of why you do platform engineering we're very end-user sort of efficiency driven I usually think of like the ultimate constraint of platform engineering to tend to be your compliance yes so can you talk a little more about that can sorry I feel very passionately that today platform engineering is like the attempt to be a cool office from like 15 years ago where if you had beer in the fridge and a foosball table everyone was like this is the best work life balance we do I'm not saying you can't have those things but I feel like this talk about that the only reason we do platform engineering is for developer experience is very missing of the reason why it's invested in by organizations and when we look at that kind of cool office vibe and how we've actually transformed to realize that the best offices are the ones that provide work life balance and autonomy and the way to do your job and feel pride in your job not about the beer in the fridge I think platform engineering needs to go through that evolution as well and invest even more in the in the other side I would like to say that in my company the platform that we're building now is the old compliance tools coming together so in our case it's the other way around so we're never the cool people so but we were the compliance people we had the several tools that need didn't necessarily fit well together in an end to end process and this is what we're trying to do now with the platform so we're never the cool kids we still had the football and beer I love it and good couch but not not the cool people okay I think we've got time for one more question one more question have you spoken about delivering more value in the back end to make them come so what are some things that the platform can be 100% opinionated about in the back end that will somehow promote ROI or efficiency in any other way that's a great question so I think one place and speaking to the the point made of is this all about developer experience or some other compliance things is around cost so I think there's a lot of things you can be 100% opinionated about in your in your platform around how you size services how you shut things down that are in development environments on the weekends cube cost and other really great tools out there for the eco impact and money impact and those are the things you also start to buy in and get return on investment from your finance department and other people wanting to support your platform because they're seeing a reduction in cost I think those are one area you can do and also when you come again to the end to end processes what are the tools that the platform really supports so if you have some exotic let's say new language it doesn't necessarily mean that the platform supports it end to end the tools yes might independently do so but it's not really easy maybe end to end and that's where it's opinionated saying these five languages are supported the sixth one just pick and choose great we're done fantastic a big round of applause for our amazing panel