 In case you just joined, I'll just start by introducing myself and why we're here today. My name is Emma and I'm a software engineer at Spotify. I've been working on backstage for the last five years on many different parts. And yeah, as we have heard in some of the talks today, there are a lot of backstage plugins and backstage is very flexible so you can extend it based on your needs. But where do you actually start? So yeah, today I have this amazing group of panelists with me and that will give you a little bit of a deep dive into those topics. So with that, I will sit down and let you introduce yourself. So why don't you start with, yeah, just your name, your role, the company you work for and maybe why you started use backstage. Yeah, absolutely. I'm from Zalando. I'm head of developer experience of Builder Productivity. Zalando is the biggest fashion e-commerce in Europe with more than 50 million active customers. We have more than 2,000 engineers and six engineering hubs across Europe and more than 4.5,000 applications of microservices across the company. And that's one of the reasons why we started going for backstage and using the platform. My name is Dan Laird. I'm an engineering manager with OVO Energy. So in the UK we supply about 5 billion people with electricity. We don't have anywhere near the scale that Levy just explained. We're about 400 tech people, 10,000 employees in the company. We started using backstage when I joined the company a couple of years ago and primarily to try and give information to the engineering community because in a remote first company you can't rely on the coffee conversations in person anymore. So you have to give a portal for people to actually understand what's going on, where it's going on and who you should talk to. Hi, my name is Bogdan. I'm working on the company Ball. It's the biggest e-commerce company in the Netherlands and Belgium. We have about maybe like 10 or 12 million customers. We're using also like more than 1,000 microservices in the company in such kind of the scale. I'm like lead engineer in my team. And also I'm recently from the end of the last year, became maintainer of the SkaFolder. And I was also really enjoyed to see one of the topics which was today in the morning presented by Helen regarding the SkaFolder retrying stuff. So that's what I'm like really actively working on. On the backstage we started working on that like four years ago and I was even like checked on adopters when we were there and we were like second company we should start it like adopting the backstage. Our primary goal was to have the backstage for the engineers so they like when they start in the morning like they're drinking the coffee and they're looking at monitor. They can see what they should do today. That's our primary goal what we're still going on forward to date. We are still like on our journey but it's like primary goal to make engineers happy so they know what they have to achieve. So far we see like the most of the traffic comes very instantly from the search. You're like building one thing but you see like when customers how they're using that stuff engineers they're using completely different. So we're investing much more time how we can make our customers more interested in other areas like for example we invested a lot in the scaffolder but it's not the thing what you use every day so we understand but it's really minimized the how many load for the engineers you have how many checkpoints engineers have to deal with and it's like a big investment which you can see like in the long term. Hi everybody my name is Alex and I work as the head of platform engineering at a fashion brand called H&M and the reason why we started using Backstage is because we needed a front end for our platform engineering ecosystem. Thank you so much and earlier today Helen did a little survey in here in person where she asked like okay which stage are you in your adoption journey and we definitely have people here just started to check out Backstage or doing proof of concept and or have fully adopted it. So I'm interested to know and maybe Levy if you can start like I know you were using two different strategies to actually go from having a proof of concept of Backstage to roll it out and get more users to use it can you tell me a little bit more about that? Yeah absolutely so the way that we look at it is that we try to tackle to customers basically one being the users of our instance of Backstage which is called Sunrise internally and the second one is actually basically the people that would contribute to the platform because we knew back then around three or four years ago it was just two three people in the team that was working on this and we knew that we wouldn't be able to achieve everything by ourselves so we really tried to do it in a way that would be very easy for people to actually contribute and start contributing to the platform so taking away things like for example authentication or taking away things like for example the local development environment or the CI CD pipeline how do you actually deploy and update the changes or receive the changes and so on and we started on the first customer meaning the people that would use Sunrise or Backstage back then by looking into what were the things that actually people needed and what would be the value that we could bring to them and that was back then a big problem around like how do we discover information how do we get access to every resource that we have and we look also at how fragmented the whole user journey for software engineers were and we really tried to step by step increase the coverage of the tools that we had in the company to actually have it integrated in our platform so when we started our first MVP was very simple with search, with catalog, with tech documentation around from the 2000 engineers that we had back then and we still have around 400 of them started already using it daily when we release and today we have around 60% of the whole software engineering family actually using our platform every day and more than 85% using it weekly it goes beyond the software engineering job families for a monthly basis where more than 2.5 thousand is using it actively in a month 2.5 thousand engineers so we focus quite a lot on our homepage and how we actually presented the actual information as my friend here said and we invested quite a lot on that as well so on the integration side of things we actually got 36 plugins that were contributed internally created either by the core team or by contribution for more than 120 individuals across the company got it, cool and Bogdan, you had a little bit of a different strategy and I won't spoil too much, I'll let you talk about it more but can you tell me a little bit more about how you were rolling backstage out to your users? Yeah, our strategy was a little bit different before we have kind of like a different internal portal it was kind of like a catalog but with only the data what you have kind of like microservices and who owns those microservices what we did we replaced it completely with the backstage it took some of the time for us to have all the features there and we also like adding more features more sources from different things there like for example you can think about like LDAP or you have like something of HRR you have SRE and other things which are contributed together so you have your catalog which is way more there plus you can also now to search really quickly there that's why like our customers like our engineers really like our search because you can search documentation you can search confluence you can search catalog from different sources and that's the biggest power going there because whenever the more sources you supply to your system the more people like it because they can find what they're exactly looking for and that was a really nice experience from the user point of view we had some kind of experience okay now if I didn't find anything in the backstage then it really doesn't exist and they also had some of the experience like adoption for example we have kind of like user interviews we have in our company UX designers they are coming to the users to use it can we for example go with you and have some feature and test it with you our advantage is like yet another system maybe like not with me maybe someone else but after they're looking at it how that works they really love it and afterwards they like said to us yeah it was really so great I would like to tell about that system to my team as well because when you're telling something to the people okay we have another platform and they think oh yet another one come on guys yeah okay Alex from a platform engineering concept lens I guess what was your strategies yeah so essentially what we do is that we again really try to use backstage as a front and for platform engineering so when we're rolling out backstage actually what we're doing is rolling out the platform engineering concept right to different teams and as a natural part of that backstage is part of that package essentially so we look at the platform engineering end-to-end journey and then we see what we can actually surface in backstage so we focused a lot on scaffolding and then surfacing engineering metrics and then compliance to guard rails has been our strategy and that's really what we're trying to do we're not trying to push backstage we're pushing platform engineering and backstage is just the front end of that ecosystem got it we'll go more into details of plugins soon but I'm curious so these platform teams also like these teams own the plugins then that you bring into backstage as well is that how you're organized yeah so what we essentially do is we in platform engineering dictate the end-to-end experience that we want to see and then we have different teams collaborating with us to essentially contribute with what they want to surface from their standpoint cool and Dan do you want to add anything around from all the energy around your strategies for rolling out backstage well I think being honest our strategy is a tale of two halves really the first part was you want to get excitement about using backstage and so you're sort of trying to promote it internally but we fell into a trap being honest with all of you guys which was sort of a bit of a sugar hit we kept adding new plugins wow look at this this is brilliant and some people ago that's good but you can only add so many plugins and keep the sugar going before you hit the sugar crash which is and so what like what are you building so we're now sort of on the bottom of the crash if you like where we've introduced these plugins got everyone really excited and the so what bit we're sort of heading much more in the direction Alex has talked about which is we've got tools out there that we want people to use in a certain way and now we're starting to build a sort of more coherent user story rather than just a sort of fireworks display of new plugins every couple of weeks which builds and promotes internally in the company which is a key part of any journey but now there's a so what question and now we're answering that one cool okay perfect you've already started to talk about plugins so let's dive a little bit deeper into it so there's a lot of great open source plugins out there and I feel like most of us starts with okay we have this set of problems within our organizations and how do we actually go to find the plugin plugins that can help us solve these so can you talk a little bit more about which how you were like identifying these plugins that can help you or solve your problems that of energy yeah so they're again going back to sort of the sugar crash and the sugar sort of hit analogy we went for some plugins and there were there were two parts the plugins that looked impressive not necessarily the most useful for the engineers but they sort of created excitement around what we were trying to do so we just essentially go to the backstage portal and go oh yeah that looks quite good let's try out the Kubernetes plugin because we have some users with Kubernetes but in reality the plugins that were actually proving more useful were where they were more focused on specific issues and we were trying to sort of answer a question within our company around ownership but not necessarily just ownership of microservices but also ownership of knowledge and that led us very early into an early conversation with Spotify themselves around skills exchange because when you've got a distributed workforce trying to identify who's got what skills and how to sort of find that knowledge is really hard now again as with all adoption journeys like the idea is sound the tool is perfect the plugin is definitely got promise but we're still at that stage where we're trying to get enough critical mass you know push that snowball down the hill because until you've got 20% of your team declaring their skills essentially no one's declaring their skills but as we add more people into skills exchange that sort of creates that excitement factor because it's something that isn't answered in any of the other tools that are at the company but yeah in the whole there's a plugin for everything in Backstage and the best thing is just try them and see if they work but just beware the sugar crash if you get people excited and then you have to maintain it afterwards love it and Alex you were talking to me before about like that you at H&M at define what's good in text before in terms of software of course what are you doing now instead yeah so what we try to do at the beginning at H&M is essentially try to explain to our engineers what good looks like essentially and the way that we did that was basically in text right and we realized quite quickly that you know everybody has different understandings of what's actually written in text so what we actually did was starting to work with Soundcheck to actually start being much more concrete about what we mean with for example you know have performance tests being ran before launching something to production are you running vulnerability scans those kinds of things that really allows us to both be clear to our users it's a better user experience and also track it at the organizational level and actually help out teams when we identify that they're lagging behind in some areas we can actually talk to them and actually show them the metrics of this is where you could be better it's also being great being able to service these metrics to engineering leads and management saying that we are making a difference in terms of being better at building software in terms of how you are identifying plugins you have touched both on like discoverability, homepage anything to add there yeah I think like with the identifying plugins it is about also like I think it's more than that right it's like identifying problems that are worth solving and where actually in the user journey people are losing time where they're actually having some optimal experiences or you know struggling with feedback loops so I try to look more from that perspective of where actually people having some optimal experiences what kind of problems are they having and then working backwards from that and then identifying which kind of plugins maybe on the plugins on the plugins page or even general github search on what kind of solutions are there to actually help people in the end and I think that has proven quite valuable for our engineers because then there is a if people know that the product is going to solve a problem they're going to come back to it and you won't struggle as much with adoption if they really see the value on this from our experience usually like what we did like initially we went through all the plugins and we immediately like eliminated what kind of plugins we are interested in and then in that set of the plugins we started like evaluate of them like how much effort would require from us to start using them if that effort is too high maybe it's not the place to start working and using those plugins maybe we can build our own because in our team we have not only engineers we have only X designers we have also data analyst so we are looking at all perspectives how the plugin will work if everyone is happy about that and we can find the ground it will be like holistic approach because of the most like appliance they don't look holistic and then for us it's like a biggest problem at least in our company and we need to invest time to make it holistic and if you see that solution not really for us maybe it's better to build it's our own and it's not only about us we all the time going to the users we are asking users how do we find it is it like easy to use is it not what was for you the biggest struggle and only after that when we have all the discovery with X designers with all the like with some set of the users with some set of engineers and when we have some data that it really will solve the problem then only we start building it start like including the plugin not right away okay it's nice it looks cool it's so much she grabs there let's like enable it and see how it goes now we are going a little bit differently thank you so much okay we'll open up for some questions from the audience anyone have any questions I'll run around with the microphone let's start it hey thanks for your insight I had a question so you mentioned infrastructure I was wondering why there isn't more let's say data infrastructure plugins or things like that that are available with backstage do any of you see your teams managing their data infrastructure through backstage or is that just not a great use case thanks I think I can take that one yes we do have seen users wanting to have data integrations we do in Zalando have the whole machine learning platform or an orchestration running the visualization part of it also in in our backstage instance yes it is a problem that we are also tackling and solving with backstage as well if I may we're the same as well actually we've just because we're trying to use backstage as a portal that declares ownership so although the data teams have got their own specific tools like data hub which is around Acryl and there's some other tools out there and we've got Kafka infrastructure and all these things what we've done is just use things like Google API to give us a list of all the big query data sets we have and we just attribute those as being owned by teams and even at the simplest level that gives you something valuable for those guys there's loads more that could be done if you're employed at the company so then you feel like you're moving deck chairs whereas the ownership piece was something that wasn't necessarily solved so we added that an account company we're also doing the same but now we're doing only the first day of the experience whenever you create the whole infrastructure the application and deployment part to the user so you just need to only supply what kind of the name of the application would be and we will completely spin up for you everything what is required there for example you want to add database or you would like to add something else but it's a little bit on the future because we're building some infrastructure heavy things and only after that we'll start building backstation top so it's also like in our plans awesome thank you how are we doing with time okay cool thanks thank you very much for the very insightful panel discussion so I wanted to talk a little bit more from all of you on the day zero before you started using backstage I guess you all had your own IDP where you had your users already using some platform more or less abstracted or more or less exposed I think on infrastructure level so I wanted to know how you went through your initial IDP and then how do we want to use backstage why do we want to use backstage so it would integrate with sometimes the in-house abstractions that you beat for your own developer platform so could you explain more on how you went through that stage to ending up with having backstage for your users I can start before we were using backstage essentially the entire developer experience was CLI based and then we noticed we were not really happy with it and we also spent a lot of time on making it compatible with different operating systems and that kind of stuff and then we had this brilliant idea let's just build a frontend and then as we started to build it we were like okay I think someone has saw this problem before so then we actually started looking at the market we did a bunch of POCs with vendors and looking at different open source solutions and that's how we basically ended up with and the user need was in our particular case the instantiation of new software services was just too clunky essentially in our experience it was started like four years ago before I joined but what I heard there there was like kind of like you can imagine we have like 50 different systems and you even don't know where you need to go to and there was like very enthusiastic idea to managers and they were so happy about it really like a dream yes let's do it and that was just kind of like a beginning to do some kind of a little bit playing around with that and yeah that was our journey so for us it was not really like one IDP itself it was a combination of different things from application registry to documentation sites publishing mechanisms or things like that and the way that we did it was basically when we were looking to solving the problem of like how do we reduce that fragmentation that I was talking about we had more than a hundred and something different kinds of portals or places where people could find information how can we create one unified thing and how can we actually do it in a way that others can contribute because with a small team we were not going to be able to do everything by ourselves and then we started looking at this and this was about the same time where backstage was released on the open source as a beta software and that's where we actually you know look at it okay we are trying to achieve the same thing let's try it out let's do a hack week two weeks see what we can do and you know in two weeks we basically got like five different things integrated and we were like okay you know I think this is the right things for us to try out and even though it's early stages it might take some time to get on stability level or maturity level that we want to have but let's contribute to that as well and I think that was our journey Yay to hack weeks Hi I wanted to follow up on this questions of how to treat your fellow platform teams also as a user and for example Levy you mentioned that you had 39 plugins being contributed from like other platform teams what were like your learnings in terms of what worked really well and what didn't work in terms of enabling contributions from other teams to the backstage portal yeah so what what didn't work well I think it's like trying to just have it organically or just pointing people to documentation we had like very good documentation onboarding material for people to start and that doesn't doesn't necessarily work well I think what works well it's really about saying you know what let me spend some time with you let me show you how it works let me show you our vision let me show you what we want to achieve and see what parts of the product as well make sense to have it in the portal which part does not make sense it's better off you know the source of the truth and not in the visualization layer so having those kind of like really hands-on discussions with like engineers talking with engineers and really showing showing how it works how to create a new plugin having those demo sessions I think that's what really worked for us especially when it comes to people that are not so experienced with JavaScript with TypeScript or from technologies in general I think that was our journey do you want to add something to that then I'm just going to say from our point of view we actually haven't made it work yet and just again, the point of these panels is to be honest about the story we haven't managed backstage was deployed by us as a developer experience team and therefore the other parts that might contribute plugins were always another part of the organization which means that there's always sort of communication structures that make it very hard to make these things work I'm hoping that's going to change now for the future engineering team and the production engineering teams all with developer experience so now we're going to essentially take the same approach that Levy talks about sit with people and say how can we help you solve a problem recognizing that there's a steep learning curve if you look at a backstage plugin and say why don't you have a go it's a bit harder than people would like to start with so we're going to have to hand hold through that journey there's also the fear there's this immediate fear of this unknown thing called backstage I'm going to start with you Alex awesome, thank you so much so before we wrap up today I know there are people here or I think there are people here who will be like I'm going to start to use backstage tomorrow so if you have the chance to give them one advice in their adoption journey what would that be and maybe start with you Alex my biggest tip is focus on the user and the product that you're developing if it brings value to the users then people will onboard to it use it I think the same how much value backstage will add to your company but also from our point of view we really would like to have contributors and what we see in our company that whenever you don't have type script based company it's really hard to find people who will contribute whenever people stop it's type script, I don't know it's like a big ecosystem so you need to invest your time and they need to be enthusiastic some people even like whenever they hear it's type script, no I'm not going to do that you need also to consider it I'm going to be a bit cheeky I'm going to add two things the first is it doesn't have to be type script so for our engineers we've written plugins in Go and it just outputs JSON files and then backstage JSON is really easy but it opens up a whole other part of your organization to contribute rather than going I don't know type script and the second quick point is don't start with a catalogue we tried to start with the catalogue and it involves so many stakeholders from the wider business that it feels like you're wading through organizational and people problems rather than solving engineering challenges whereas if you take the approach like Alex has talked about you can't find that amount of time so start there I think it's very similar to TRs I would say like pick one use case there's the most impactful one for your organization and tackle that an example there was an incident a few months ago somebody said it took me like two hours to find what was the change that happened in production so we say okay why was that then we create a plugin for saying okay the latest deployment so that this doesn't happen again so it's just one example it's really about not trying to solve all the problems at once but really picking one the most impactful problem and say okay how can I solve this problem how does backstage contribute to solving the problem and then from there really it will open up the doors because then you have impact you have trust also from the you have trust from your team as well that they created value and then move from there did you want to add something yeah just something that sprung to my mind I think yeah solving problems but just a caveat on that also not solving like individual problems in isolation I really like to think of it as like let's look at the end-to-end experience right because if you just solve particular problems but then distributed problems then there's no real there's small added value you don't get the wow effect to come back to backstage all the time awesome thank you so much for participating in this panel today and thank you for listening and having great questions and yeah I have a really important thing as part of my speaking notes and that's to show the QR code that you can use to give feedback on this panel so scan this one and thank you so much and yeah give them a round of applause everyone