 All right, folks. Let's do this. So let's please welcome Helen and the amazing panel she put together for us. Here's your front seat to adoption, right? Literally. So strategically, I'm going to take this little space to look up to my role models and developer productivity practitioners. So yeah, bear with us, a little weird Sarah. But yeah, trying to make it work. All right, so why adoption? Why, again, this day started with hearing about older adoption insights from David. And there will be more adoption stories throughout the day from end users, from vendors. Why do we think this is so important? Essentially, backstage is a platform. It's so flexible. It's so versatile. It has almost infinite possibilities for customization. And there is truly no single right way of doing it. So it is really important to hear all the real life stories from all the really, yeah, just experienced developer productivity practitioners, which backstage community has a lot of. So I feel really lucky and fortunate today to sit next to such a powerful panel. So please, please, please give them a shout and a warm round of applause on my behalf. So yeah, before up, yay. Let's do it. All right, before we dive into questions, let's do a quick round of interest. So I'm going to start, those of you who have been around since the morning, probably already sick of me. But for those of you who already joined just now, I'm Helen Greil. I lead engineering for Backstage at Spotify. Hello. And falls, can you do me a favor and just quickly introduce yourself, your name, your role, your company, and what's your current involvement with backstage? Let's, yeah, start with you, Alec. Hello, I'm Alec Jacobs. I am a software engineer for Twilio, specifically this segment side of things with our CDP. We've been working with Backstage for about a year and a half now. My team specifically focuses on building it out, and we're kind of in the middle of it. It's great. Cool. My name's Casper. I work at a company called Lunar. We are a challenge at Bank in the Nordics of Europe. We've been working with Backstage for around three years now. I've been sort of one of the architects in that process. And yeah, we've been basically helping out developers as much as possible ever since. So yeah, happy to talk about that. My name is Poonam, and I'm currently working in US Bank as vice president and with my involvement for Backstage. So this is one of my PO team is building into it. And we are closely working together. So we are in the middle of the Backstage still. Hello, everybody. My name is Guillermo Monzo. I'm an engineering leader at Expedia Group. Our team is a core Backstage team, per se. And we support over 6,000 developers and the collective EG community. Awesome. Thank you all so much. Yeah, let's dive right in. We don't have a ton of time, and I recognize this topic is massive. So we could be spending hours on just that alone. So the questions we get along, like how did this whole thing start for you? Like what triggered the question in your mind? Like I might need something like Backstage. Was it all like scientific, or like, yeah, how did it just come about in your company? Guillermo, when I kick us off? Sure, why not? So for us, Expedia has multiple brands. I've probably heard of that, Verbo, Hotel.com is two of the bigger brands that you've probably heard of. And so a couple years ago, there was a major push to kind of centralize the brands. And by centralizing, it's the fact that all developers are deploying software in various different ways, managing their software. They have their own developer portals that they're creating things from. So as there was a push to centralize the brands to make it easier to develop travel products, there's also a push internally to centralize developer portals. So there's a little bit of user research, reviews, build versus buys. So ultimately, we ended up with Backstage after reviewing our internal portals, cost paid portals that were out there at the time, and realized that Backstage was the best choice for us to kick off our journey. So we've been doing it for about three years at this point. Awesome, I'm almost since the beginning, right? Number 18. You're one of the OGs. Right, number 18, like, hey, Manny. Awesome, what about you, Poonam? So I would say like, first of all, I belong to the financial industry, and we care about people's money, right? That's how I would define myself or my company. So initially, when I joined this org, so we identified like there is a challenges in both the site, and we call them as a frictions, both at site like technology versus culture. Technology, I think like my friend already explained it, we have similar like the experience. We have each business segment, sub-business segments have its own manual processes of onboarding. Some have already buy-in tool, and even though they have a buy-in tool, but they have limited set of features approval, and no one has a visibility when those tools are out, or maybe they are discontinued. So every time we are lack, and every team is working in a siloed, like okay, there is an X team, which is working, they build their own developer for platform versus Y team. So it is very difficult to track on it, and definitely it is like a cultural thing. The cultural thing is what I said like siloed, no one talks to each other, so every team is building on that part of it. And then we come up with like, when I started, where my team kind of jump into it, before Backstage, I'd be honest with you, we build our own customized developer platform tool, in order to standardize this onboarding platform for my user, that's my user is none but app engineers, developers. And when we were building into it, we have like, we had couple good wins, but we have like couple, you know, opportunities. And last time we also called it out in the Backstage, like the opportunities were more about like, how many personas we are trailing, we are literally covering into it. And honestly, we were just taking care of only CLI persona, we have many personas that Backstage do cover. For example, managers, you have like auditors, you have like teams, and plus you have like leadership has a view of it. So that's where we kind of figured it out, you know. Can I embed this custom tool or use my customs tools template easily on Backstage? It was pretty quick. So one of my engineer was really, we did the POC and it worked out with the Backstage and in a matter of five hours, it's an open source. So we got really a good buy in from our leadership, demoing multiple, multiple platforms within our organization, stating that like, you know, Backstage is one of the unified platform. It does have cool features. We can experiment on it. And that's where this journey started. And it's been, this is our, it's almost like two and a half years. Wow, exciting. Yeah. Many can relate, I'm sure. I'm sure. Kasper, what about you? Yeah. So yeah, as I mentioned before, we've been using Backstage for around three years as well now. I think for us, it was really, we've been building platforms before that we were a tech startup and we were been building a lot of CLIs. I guess many people have been building CLIs to build their own platform. And we have quite a few CLIs and CLIs is not always sort of the best way for every developer. So we needed a way to cater for some of the other developers as well and basically provide some better tooling that we were already providing. So when we saw the demo that was the demo video, when Spotify open source Backstage, we were like, that is the tool that we need. That is the exact problems that we see and we just need to have that tool. So we started adopting it, I think three or four months after it was released. Starting with the catalog, we were pretty lucky in the sense that we already had a file in all our repositories that were defining ownership, the name of the service, a lot of other things were defined in this file. So for us, it was pretty easy to just, you know, create a process that would get all the information and create components within Backstage and automate all of that process for us so that whenever a new repository was created, it was just in Backstage right away. So yeah, I think for us, it was basically getting rid of the CLIs and not getting rid of them, but sort of find a way to combine that with a more visual tool and have the catalog. But also, we were also looking at migrating or finding the right tool for documentation because we all know that centralized documentation doesn't really get updated, it's horrible, so we also needed a way to do that and Backstage provided a solution for that as well. Fantastic, yeah. Yeah, I guess that follows maybe some of the patterns that David was sharing this morning about ways to adopt. So yeah, I'd be also really keen to extract the patterns from your journeys a little bit and see what other things we have in common here. There was a mention of Twilio, I guess, and David's talk, so yeah, let's hear from the source. We're lucky to have the source here. Yeah, so for us, especially on the Twilio segment side of things, we were a pretty quick startup, accelerated a lot. We had a lot of our own tooling to do a lot of things, similar to what Casper mentioned and everyone else, but we didn't have a good way to answer the question of ownership, so we had our main focus and the problem that arose naturally was how do we understand what services and tools are actually running, how do we get in contact with who owns them, basically solving the taxonomy problem. So that was the problem that our leadership was fully bought in on solving. We stumbled upon, we had a couple of internal tools that didn't try to solve it, didn't really work for solving it, things got stale so quickly, so we needed a better solution, having the catalog info.di animal files directly in the repo, right next to the code where people are working, that's working for us and helps keep things up to date, so we kind of went all in on solving for taxonomy, catalog, making sure we can really answer that question of who owns what, how do I talk to them? So that's sort of the start of our adoption. We're still kind of growing a lot in the sort of developer platform and developer portal space within Backstage, but Cattle Growth is really kind of where we're at. Awesome, yeah, I guess a lot of teams just start with that ownership problem and that is a powerful vehicle to adoption as we can all see, I guess. Yeah, Guillermo, you mentioned to me before we met today, your thoughts and ideas about what's the ideal concept of ownership for, I guess, yeah, Backstage as a platform as well in York, could you please, yeah, maybe tell us a little bit about how it works, how you came to the structure that you have today? Yeah, so when it comes to us, when we started launching Backstage, we did start with trying to centralize documentation, the tech docs, and we already had the concept of, I wouldn't say like the concept of ownership, we're the concept of ownership management, right, so we kind of knew who owned what we say, but we just had various different databases in order to manage that, so we centralized that in Backstage, that's what got us the original adoption, but what allowed us to scale was actually the plug-in contribution model, and that's kind of where people are able to, we've essentially automated the ability to create a portal within Backstage, right, and so we worked with a lot of different teams that had their own problem solve security, reliability, governance, et cetera, and we worked with those teams to enable them to have that automated plug-in creation and self-serve, so when it actually comes to ownership, we, my team, or how should I say the core team, owns the SRE management or the reliability of Backstage itself, but we've already self-serviced and enabled that general management of a plug-in ownership, so every team that built a plug-in essentially owns the interface, the code, the problems they're solving, but we take all ownership of upgrades, incidents, and general management, and that allows them to focus on building products while we focused on managing what they're building, if that makes sense. Totally, totally, it does, it's a pattern we also see a lot and if you can probably talk to some of the engineers in Spotify, they would probably tell you the same story of how it works in-house as well. Any other takes on how it works? Yeah, I can definitely relate to that because you're probably not as far as you are, we're also a fairly small team, we are around 120 people in tech in total, but we also have a centralized team that owns Backstage, but they own a lot more, but they are building the platform and providing the platform for all the other developers to pitch in and in a source, in many cases, plug-in. So we have seen two examples of in a source plug-ins, which has been absolutely amazing to see that when we provide a platform that developers are really seeing the value of building something that can run in that platform and they take ownership of that thing. And this particular thing was around doing reconstitution of, so we're doing a lot of event sourcing and developers needed a way to and interface where they could basically specify which event should be replayed for a given service at a given time from a given point in time and they provided that information or that plug-in and then it's now available for all developers in the organization. So I really see a lot of value in that model and it works really well for us as well. Yeah. Awesome. And I think that's what definitely has helped with plug-in ownership in general, because when you're asking about ownership there's catalogs like owning an entity and usually the thing there is just when it comes to catalog is just getting a list of all the services that are used throughout your customer platforms and everything, right? Not just Backstage itself, but when it comes to scaling internally that plug-in ownership is super critical because if developers are concerned with, oh, who's gonna support me once I build this thing for the community then they're at least likely to actually go out and build it, right? So as we, since we took over that ownership of managing all plugins and centralizing the automating it, the plug-in model itself has scaled drastically even further than the core team can even handle. So we just keep building more and more automation to manage that. So, good call out at the end of sourcing. Yeah. It feels like it just explodes at some point which is a good problem to have. What was the tipping point for your organizations, like any other takes on enabling in their sourcing in York through that? Yeah, so it's interesting because there's a couple of different tipping points when it comes to Backstage. Like I mentioned earlier, our focus is on getting the catalog up to date. And for some other organizations that might be expanding contribution, getting other people to work on it. We're starting to get to that point, we're not quite at that tipping point of contribution but for getting your catalog kind of setting up to date, the tipping point was just us having, David called it out, we have the catalog health that just kind of tracks things. We can set our understanding, set our goals of, hey, we were trying to make sure that we're covering all of our production ready services in the catalog. How do we get the owners of those to actually define the services for them? And it's sort of injecting Backstage into their workflows that really helps get that tipping point, especially of adoption coming over where they need to start using Backstage, they need to start defining things a specific way for things to just kind of work. Search was actually a really big one for adoption. As a company that got acquired by Twilio, we had multiple different forms of documentation. So actually searching across all those documentation, putting that in Backstage, people just started naturally using and adopting Backstage, which was really important for us. For us, as Alec called it out, we are mainly focused on using the documentation part and that's where the adoption is going on in the US Bank site or in the financial because it is very easy, but we recently created an automated way to build the docs and that's where the tipping point for the Backstage, like, okay, you know what? It's not about creating, using the template and build the docs, but you can automate those too. And that's where we have seen people start adding, as my friend called it out, like, you know what, having the plugin ownership, having an inner sourcing model, okay, if I could do this with this plugin with an automated way, wow, it makes my life, developers is wow, it could be done in a single day in a pretty quick minute, I didn't know about that. So that's where it is like, we have seen now other engineers are starting exploring more plugins, but the plugins, which is they can customize as per financial industry standards and that's where we are seeing like, a lot of people, a lot of engineers are making inner source contribution looking for it. That's how it is. Yeah, it's really powerful. Is it fair to assume that, like, you go through phases, right, with that? And there's definitely some kind of sequencing that's probably is involved for success. Yeah, what was your approach to phasing? What was your approach to road mapping maybe? Since, let me talk with the finance industry, because I mean, I'm like, I also speak out, I mean, I literally talked to one of my first person who reached out to me about the same thing for the backstage, like, where are you in the backstage journey and what it looks like. I always say like, it depends on which industry are you in because if I'm at retail, I may be so far, I may have adopted all the plugins, having inner source contributions and having everything done pretty quick. But when you are dealing with like a finance industry or a medical industry where you are dealing with your customers data and which are crucial, right? You have PII and PCI data. You really need to have to think before, you know, everything needs to be customized. You cannot use plugin right away what open source provides it. You need to wrap it in a way. So, my answer is like, where are you in that journey? From the finance side, I would say like, we are still adopting and we are making our form case, like, you know, it protects everything because we have everyday calls with auditors and risk and compliance and securities because they keep on asking, they are double checking with us for everything. Like, are we sharing these data externally? No, so they are defining and we are also educating them at the same time. It's not about like, they are saying like, you have to do this. At the same time, we are also maturing in their understanding how this tool works. So it's like learning, educating and building those risk and controls in place to, you know, where you can make your apps. Like my friend said also, I said like app hygiene and metrics to be captured in a way that like, it's not exposing to rest of the world. Yeah, I also want to add, so I'm also in the financial service industry and what we also saw that after us developers were sort of adopting backstates, they actually saw, oh, this can actually help us a lot in being compliant and show compliance to our different auditors and the Danish FSA who was regulating us. But having the catalog, the software asset catalog, defining the ownership, defining critical journeys, maturing, all of that, we've also integrated. So we have journeys, a concept we have added to backstage. So a user journey, a tier one journey is a journey that requires on-call if something is wrong. So if our customer service agency, something wrong, they're taking a call, they can actually trigger the on-call team on that specific journey. So we've just been seeing a lot of different stakeholders seeing some real value of backstates and other than just the developers. So it's quite interesting, it's been quite an interesting journey. And we are now building towards having all our SOPs and stuff like that defined as like facts and rules that we can check on the different entities, the different things we have in backstage. So we can say that on this particular service, everything follows best practices. This is compliant, this is, and we can see that on both on a squad level, on a team level, on the organization level, and the teams themselves can also see, hey, I'm not compliant in that particular thing, then I need to do something there. So that's just another different use case for backstates as well. One thing, you mentioned the developer journey, right? And so usually the first part of the journey is onboarding, right? So one of the things that we put a lot of effort in on the scaffolder in this case is what we call our onboarding platform is we try to give compliance up front, right? So thinking about like paved road templates, right, community templates and whatnot, we saw a lot of value of bringing compliance up front to all these apps. So we actually created a program called like Ship on Day One which focuses on those type of compliance metrics. So if we're able to offer to the developers, you know, he used this template and you pass all these auditing controls and whatnot up front, we saw a lot of value of teams leveraging those paved roads and that's probably one of our most stable platforms that's kept us consistent past that tipping point of adoption, if that makes sense. I love that you mentioned onboarding. I guess as much as like the industry is waking up to the importance of developer productivity, onboarding is one thing that I didn't think gets enough attention, it's really important to get that like day one type program, I truly believe. Alec, we're going to add something. Yeah, I just wanted to add on to something Kasper had mentioned about tracking compliance and making sure things are for date. One of our goals is to make sure our service readiness framework is completely existing in backstage, so it's easy to view. People can, or developers can track where their services are at, but on top of that, just enabling initiatives that extend like service readiness framework. Like we, our compute team might need to update all of our EKS clusters or Kubernetes clusters to a specific new version. We want to prevent any like new spreadsheets from being like created to track that. Just like, okay, okay, go to backstage, look at where your versions are at, you can do this query, see how everything is, and you get instant tracking of how things are. So that's one of our goals, that's what we're building out, and yeah, it's really powerful. Yeah, we should probably restate the mission of backstage to just kill all the spreadsheets, right? Yes, yeah. That could be pretty powerful. Give me your mark, yours too. I can tell you that, that goal is going to work out. Yeah. That's definitely one of the main things that I was mentioning to you, working with the various different teams, the Expedia Group, that are trying to do that compliance, right? Production readiness, governance and so on and so forth. So by the core team, by us helping out those teams scale their platforms first, they're able to bring compliance to the rest of the software catalog, and that's how the majority of our adoption of who uses backstage is, I'm going to check my security compliance, I'm going to check my governance compliance, I'm going to manage my app, right? So although the software catalog took a while to take off, and that wasn't our bread and butter, it's almost where everybody went. It's the output of where everybody goes, if that makes sense. For sure, it does. Yeah, one thing that I was going to bring us back to adoption for a second, as in adoption prerequisites maybe. There were some things that David also had mentioned in his talk as this, like I've seen this and that pattern when it comes to which adopters are more successful than others. Can you share anything about what you've learned through your adoption journey? What is the most important prerequisite for a number of prerequisites for backstage adoption? Yeah, for us, so we actually came out, we've already launched two blogs already about this, but we came out with the proof of value metrics. So Spotify had already provided some subset of metrics that are, when it comes to developer platforms, are pretty easy to pick up. NTTR, when it comes to Dora, right? The goal of backstage is centralization and reduced context switching. But we started focusing on proof of value metrics and really it was our way of communicating with the senior leaders to explain to them what are the problems we're actually trying to solve. And so that has been very successful for us. Again, those are like platform level metrics around backstage specific, but we're able to tie some of those metrics into other input metrics like onboarding and so on and so forth. And that's kind of what led us to the more visibility into the adoption cycle. Again, a lot of the senior leaders tend to be more interested in understanding the current value add and the current state. And so definitely would recommend coming up with some set of KPIs as we had talked about earlier, some set of KPIs and whatnot. And so right now we use proof of value. You can see that on Spotify's blog post around those metrics. Thank you. Yeah, KPIs are a huge thing for us, making sure you actually, you've talked to your users, you've defined the problems you're gonna solve. I think that was mentioned earlier in the five tips for success was actually make sure you're building, you're solving the right problems and not just building it for the sake of building it. And on top of that understanding that it's an investment. It's a service, it's a platform that you're building. Backstage is just the platform, you're building a service that other people are gonna use. It requires investment and being able to actually manage that is pretty important. Yeah, I would say for us it's really about integrating critical paths and systems into Backstage has really helped us adopt Backstage and our developers. So right now at Wunder, you cannot create a Git repository in GitHub anymore that goes through Backstage and all the Backstage templates. So we define what repositories should look like. But that was also, it was both like a compliance thing that we needed to ensure a lot of things here. But we also, at the same time giving our developers a lot of nice ways we went from, it took around two days maybe to create a service to like five minutes now with the scaffolder. So we gave them something and we got a lot of out of it as well. So integrating critical systems and paths has been really critical for us. Yeah, I agree with Kasper what he's saying, like yes, integrating the critical systems, that's the first thing. And the second thing, like what I agree with like KPI matrix. So for example, we are able to see that like, okay, how many projects we are able to create by our app engineers onto this using Backstage, right? And then they are using the Backstage because Backstage is a front for our customers, which is app engineers. But behind the scene, we have integrated critical tools and which is could be DevOps tools, whatever it is. So when it comes to DevOps tools, we measure the productivity using Dura matrix. So that is also gives a visibility of it, like how many times are they using, deploying their apps onto the production at what frequency, how many incidents are there. So those kind of application insights and controls that we see. And in terms of compliance also, when we share to the business, like, okay, these are, these are, this is the average is compliant by this, but we're dismissing this. That's how these matrix that we are capturing and communicating to our business leader is really providing a value to it. Yeah, it seems like compliance is the name of the game sometimes or yeah, most of the time it really is. Yeah, I remember Kasper you shifting gears a little bit. I remember Kasper you mentioned to me earlier that you're trying to kind of spread the adoption of backstage outside of R&D a little bit. How is that going for you? Just curious. I think it goes pretty well from, as I mentioned before, that we have a lot of different stakeholders now using backstage. One of the key things that we are struggling with right now is that we have a lot of different authentication providers as a dish right now. And not everyone outside of tech has a GitHub account. So we have some stuff we need to take care of in that regard. But I think it's going pretty well with getting different stakeholders to use backstage for the different specific purpose things that are journeys that we've been building to backstage as it is right now. Totally. Anyone's got other experiences of like, yeah, adopting beyond R&D or has it been just R&D in your case? Like you mentioned a good point around like accounts. It's really like it's a never-ending pitch, right? It's like even the engineering leaders have to have some of the product mindset. But when you think about like account management of GitHub where product managers or customer service reps may try to find documentation, those are good selling points for why you should go to tech docs, right? So really, it's a never-ending game of collaboration and communication with the various different leaders that come in and out of orgs. Again, it usually rolls back to pointing to a certain set of metrics or a certain set of value add that you've seen, right? So onboarding has always been a great value add for why people should self-serve, create those scaffolder actions and centralized templates, right? And then the software catalog is just a good example of, we don't want to all run around with our heads cut off looking for an app when it's right there in one central location. So really it's just a consistent selling point at this part of the journey, if that makes sense. And again, solving the right problems that are coming now. So GIN AI is one that's been recent, there's recent solutions, code pilot, so on and so forth. So really just bringing the right problems to the table and solving those will continue to allow you to go on your backstage journey within your org, if that makes sense. It does, yeah, it does make a lot of sense. Yeah, I guess we touched on metrics a little bit. Guillermo, you started this kind of thread, I know you're big on metrics. Yeah, what is the single best metric in other organizations or like a number of metrics that you guys use to drive, yeah, I guess, backstage evolution? From our side, we consider developer happiness away, which we did it through NPS course, that's what our product manager runs. And so this is one matrix, we capture another matrix that I called it out, Dora matrix, that we are also building like, that comes under the apps or businesses that are using backstage, okay? That we are also capturing. So right now we are going with two. Yeah, I think for us, we are probably in the early phases of actually starting to measure sort of how things are going, but we just saw right away that we went from these two days to five minutes. So that was quite a lot. And if we look back to when we added the CF folder, I think that was in 21 or something like that. And we probably created 200 new services since that. And if you sort of add that up, that's quite a lot of our saved. So alone, adding that has proved a lot of value. And I think that's if you are trying to sell backstage at your organization, the scaffold is really an easy way to get a lot of value. You probably have a lot of different things as well you do need to do when you are creating a new service. So automating all of that and giving that in the hands of the developers, adding five or six different steps and pressing a button, you get stuff out in production, that's a lot of value. I think for us, more than just understanding catalog metrics and adoption rates, it's understanding and trying to, I guess, quantify how we're actually improving the day-to-day work life of users and developers. One of the big initiatives we have, I mentioned kind of earlier, just injecting backstage into workflows. Our security team, they need to triage issues. They need to find owners. That was a very manual process previously. If we can inject backstage into their process just by syncing our group hierarchy into JIRA, for example, we can reduce their time to figure out like, okay, who's the actual owner? Who's a risk owner for this service? What's who's the director? Who's the VP? I need to escalate this too. We can automate that and just make their lives that much easier. It's a success, so trying to understand how you're actually improving the day-to-day life of your users and developers. Yeah, that's a really good advice. I would think I would say the one key metric would probably be time-saved. In whatever format you can put that in, ultimately you're trying to lead to time-saving, right? I think that scaffold is a perfect example of that. Whether you're trying to be in compliance in a very quick time frame, trying to meet some honesty in a quick time frame, I mean, essentially if you're able to build out the paved road process that gives you all that out front, then you've saved, you've saved not only your self-time, but you've saved all the developers that you're gonna go reach out to your time as well. So I would say onboarding metrics or ship on day one or scaffolding metrics would be a great place to be a great selling point for why backstage is a great option for any company, if that makes sense. Yeah, that's a really good advice, just like I said to all the champions out there trying to sell their stakeholders on backstage and just develop their portals in general. Yeah, I guess to round this off and to make sure that we have some time to take questions from the audience, I guess one last question that I will ask you is like what would be the single best advice that you would give to someone who's just getting started on that journey or just considering whether they need a developer portal or not? What would you do? Like knowing what you know now. I would say talk to your customers. Get out there, talk to your developers, see what they are, where can you, can you provide some help, some efficiency gains by adding a developer portal? So I would say go out and talk to them because they're probably the one facing the issue. I would say figure out your frictions because then I joined the bank, this finance industry overall, coming from the retail and joined finance and I was like oh man, this is too much, means like do I have to do these manual steps to get, deploy only one app to production? Oh, then I kind of divided that thing like okay, these are my technology challenges versus cultural changes versus compliance changes versus risk and that's where you, when you face the problem then you find out a solution and when you find a solution then you look for more alternatives. So the best advice is my for everyone here is like whichever industry are you in, just see like what are the challenges, what's your first day challenge looks like when you were working as an engineer? If you think into the lens then probably, I think this is the best tool to use. Start with your pains, right? I would say I think as everybody mentioned, understanding the different personas, you're trying to support and then prioritize those personas. Originally we started with supporting contributors or developer contributors, those who are building things internally and also developer consumers but at this point we also have to take account to the various leaders who are trying to hold accountability of all these capabilities being launched and whatnot. So again, going back to know your personas, know what problems you're trying to solve per persona and prioritizing them is a great place to get yourself going. Yeah, just adding to that, don't boil the ocean. I think that was a trap that we fell into a little early and then you have to readjust and really focus in on what's the core value, what's the core thing you're trying to solve for and make sure that that's working. That's wise man words. Don't rock that boat, for God's sake. All right, yeah, I guess that brings us two questions from the audience, please, yes. Hi, Spotify has talked about the new marketplace today and they've also talked publicly about declarative integration. Are these things that will be helpful to you in particular or is there anything else on the Spotify roadmap that would be helpful to you in overcoming challenges? So, I mean, I already talked to Spotify quite a bit in the background, especially when they actually launched the alpha of those marketplace plugins. But essentially, I would say that a lot of the capabilities that those pay plugins offer are things that we've also considered as well. So, hence why we have a lot of conversations in the background. So, I would say you definitely go on the right track. If you're starting on your journey, you don't know where to start, but that marketplace is definitely a good place to go and look into. I think it's gonna be very dependent on the various different companies, like someone mentioned many authentication providers is a perfect example. But yeah, for the most part, it looks like we're all training in the right direction in regard to that marketplace, if that makes sense. Anybody else want to answer that? Yeah, I can also add that. Yeah, I think it's a great thing that we are seeing that you as a third party developer or whatever have a place where you can easily release your different plugins and different services that you are providing. So, I think it's a great way to sort of see what's out there and start trying things out. So, I really like that we now have a marketplace because that just makes adoption easier. But also remember, as I think one of the talks earlier mentioned that don't just pull things down from whatever open source shelf is out there because you probably need to tailor it anyway to your organization, to your developers, to your unique workflows, but having a way to extend plugins and sort of add the things that are specific to your organization is what is gonna be really powerful. Just want to touch on as well for the new kind of extensions and composability of the backend system as our backstage instance is scaling out and we're starting to get internal contributors to help scale it out. We're pretty excited for the new backend system and the new composability features to really help us up level that ability to contribute easily. I think that's probably what we're most excited for. Hi, I'm curious, we heard earlier that as the catalog needs to grow to a decent size before you see the benefits from it. I'm interested, the panel, whether they kind of noticed that after X number of apps or after X percentage, how did it work out in your specific case? I would say, I mean, when we did a POC of backstage three years ago, we had already 20,000 entities. We were that company that was hidden in David's presentation and so really the value we saw at Software Catalog was our ability to centralize the various different metadata stores that we had and so I guess it's a little bit different in the sense that we weren't looking at the increase of entities to show adoption of the catalog but rather we were looking at the amount of views in the catalog because we already had back the metadata stores so we already knew what we had. We just, there were five different portals per se and so it was a one. So as we started to see the views go up in regards to the catalog itself, we started to understand this is a good place to centralize management and then we started to add more capabilities into that catalog and from there the rest is standard, status quo now. I think adding onto it, it's important not only to track how much coverage there is but how accurate the coverage is. That was probably the biggest tipping point for us was focusing in on okay, we have definitions here, how much of this is actually correct, how much are the owners actually defined properly because once you have actual valid data in there you can start enforcing requirements like putting it in front of development processes, creating kind of like the carrot and the stick. David mentioned that a little bit earlier in his presentation, that was big for us is make sure things are defined so we can be in your paved road but if you're gonna do things wrong, here's the stick, get in line. Hello, I know I heard Guillermo mention this a little bit but I'm curious for any of you that had multiple teams or multiple portals that were all trying to solve the same problem, one, did you end up really collapsing to one or did you find yourself actually partnering with any of those portals together with Backstage to provide that developer experience or did you just replace it all with Backstage? In our case, it is more on collaboration side because we cannot say that like, okay, use this one. So you need to get a buy-in from your partners, collaborating teams on that part before you say like, this is the one of the two which solves your problem. So as we build that PLC knowing that fact like we have different onboarding total tools or different manual process for each of the team and that's where I said as the start of this panel discussion, like we keep on demoing those things and when we keep on demoing those teams, they keep on asking those questions that they have in their portal and it's okay, is this problem being solved? Is this being problem being solved? How are you managing the accounts? How are you showing that like this has, we have made this much compliance. How are auditors going to check all the components, audits, et cetera, et cetera? So that's where when we ask them, when they ask that question, we keep on showcasing them like, okay, this is what is covered, is it? And that's where we see like, okay, then these teams come us as together and saying that can we build, can we inner source and contribute to this? So it's like, it's never go by like, you say that and it works. It's more about partnership and collaboration. I would say it's kind of a hybrid, you know. That crushed the competition up front. Actually, so when we started with our journey, we actually owned one of the platforms already, which we were part of the core Expedia brand per se. So the first part was understanding where the journey for each of those portals was and collapsing the ones that just save some money, right? So if that's, if 10 engineers are working on this portal over here, 10 engineers are working on this portal over there. Imagine if you're just working on one portal and you can go spend five engineers worth of their time doing something else. So there was definitely a lot of opportunity and value add for collapsing some of these portals. For some of those other legacy portals that, you know, I'm sure everybody has legacy systems and about 500 migrations going on. It starts to get exhausting for them to manage their ecosystem and the stuff in backstage. So slowly but surely they started leaning in there. And I would say that we're at the final phases of collapsing, you know, the last one or two portal switch at this point are niche to what they're doing and are not competing with the developer platform itself. That makes sense. And I'd like to ask if it makes sense because you know, I need to know how much it makes sense to everybody. Mine should be short. I just want to know, do you normally end up starting backstage with Postgres in the cluster or are you all the data in the cluster or do you recommend, you know, outside the cluster? Because that's been one of the, it doesn't make sense, but that's one of the first fights I have is to convince people that it's okay to start in the cluster because this thing's awesome. So what has your experience been? Do we need it to be like a hosted RDS versus just in cluster? Well, I can start with this one. So we basically started out just trying testing if things out with just a simple Postgres within the cluster, but we are using RDS quite extensively. So we've since then migrated to just using an RDS Postgres instance there just to make it the sort of the management and operations as easy as possible. Plus one. And the last one, I think. I'm a little far back, sir. I mean, my engineer is here, so he can tell you where we're at, but we definitely did use Postgres SQL and we did use a managed cluster to do that, if that makes sense. We've heard a lot about like scaffolding, template, like creation of services, which is awesome. Do you have any tips about testing that? Like making sure that a new update to a template doesn't break, that it can actually spin up, that it has all the permissions to create the things that it needs to do, and also tearing down after that. I'm curious to hear what other people say, but we have a pretty thorough and end-testing kind of requirement for any of our template changes. There is a bit, our goal is to try to get the actual, like our Go Guild or our Node.js Guild to maintain the golden plate, golden path templates, getting them to kind of run from zero to 100, actually full on deploying the thing, make sure it's actually working, because there's nothing worse than like trying to start a new thing and then it just is broken out of the box. So we have a pretty heavy investment on full and end-testing there. Recently just created a tool to help immediately scaffold out the actual templates that are being worked on, so you don't have to run through and create a whole GitHub rebuild just to realize, oh, oops, I messed this up. So investing early and sort of reducing that feedback loop was pretty critical for us there. Yeah, plus one. That's one. Yeah, so yeah. No divide on this one. Yeah, but we automated the template creation itself, and then we've, throughout the years, we've put a lot of effort in governing the framework, not as much as governing the functionality that template provides, as there's some more paved road and some more community-owned, and we don't wanna stifle people's innovation by saying, oh, because you're not paved road, you can't build templates. So what we focused on was the framework itself. So if your template meets a certain level of framework, it has the right level of compliance criteria, then you're able to create that template and offer it to the community. Now, if you meet an even higher bar of criteria, then you're a preferred template in the community, and then obviously if you are, if you are a backed template by team-backed template, then you're more of a paved road recommended. So we have different branches of templates and we have different levels of governance to those, right? I saw some questions in the back, but unfortunately we're out of time. So you're more than welcome to chase down those brilliant individuals and poke their brains about everything that they know. Thank you so much. This has been golden. I really appreciate it. And yeah, we're just one talk away, I guess, from lunch. Thank you. Please, another round of applause for this amazing group of people. Thank you.