Transcript for "Breaking up with Backstage ❤️‍🔥": Welcome, everybody. We'll just give a few seconds for everyone to roll in. We will give thirty more seconds before getting started. Awesome. Why don't we get started? Well, welcome everybody to our webinar series. Today is on Breakup with Backstage. I'm really, really excited for today's conversation because we have the famous Jeff with us who has an amazing background, very relevant to today's conversation, having worked at Workday and seen the IDP journey from Backstage to Cortex. I'm super excited to get his perspective. Quick quick background on me. I'm the cofounder and CEO of Cortex. I used to work at Uber, which is, like, the classic case of microservices gone wrong. All the challenges with scaling your service architecture there, you know, basic things like service ownership were difficult to understand. Half the businesses lived in 10 different places, 10 different docks, or even worse, just in people's heads. And it was impossible to enforce standards and understand what areas of risk in the business were from a reliability or security perspective, which really led me to starting Cortex with two close friends of mine. And I'll hand it over to Jeff. Hi, everybody. I'm Jeff Schneider, solution architect at Cortex. I've been here about two and a half years. I got introduced to Cortex while I was at Workday. I've been in developer experience, developer productivity, big chunk of my career. I was an early employee at Workday, and back then, Workday had three services. It's a front end, a back end, and there was, an enterprise bus layer. And while I was there, that went from about three services to 750 or more. I truly lived the microservice explosion, and I saw the need develop right in front of my eyes, this need for this product space, which didn't exist. So at Workday, we tried to build an internal developer portal a couple of times. I invested, in time in looking at Backstage, and then I got introduced to a niche and the team at Cortex. That's why I'm actually at Cortex today. Looking forward to sharing a little bit more about that journey as we continue the conversation today. Awesome. And, you know, honestly, to kick things off, we thought it would make sense to just get a sense of where everyone is on their Backstage journey today. So we have a few options, whether you're just exploring or have been scaling and adopting Backstage for a year plus, or maybe you've tried Backstage and you've already decided to break up. Would love to get a sense where everyone is in the poll. So give everyone a moment just to give us their poll. Okay. Very interesting. So looks like most people are still in the very early stages or have just maybe started experimenting with Backstage, which makes total sense. Cool. Looks like we have a few people who have also been using it for a year plus. Awesome. So maybe to kick things off, Jeff, it'd be amazing to understand, you know, what problems were you initially even trying to solve with the internal development portal? Maybe we can start there. Sure. It was interesting that Workday had a very targeted approach that they were looking at with their internal developer portal. They were spending incredible amounts of manual time approving network firewall rules. So it's a very targeted use case that Workday was looking at. They wanted to automate this process. So they actually brought in a few contractors to help build an application. It was called the service registry. And what was really interesting about that for me at the time, I was involved in building a lot of test automation systems. So I mentioned this explosion of three services going on to several 100. I would start to build these services, these automation systems in Amazon, and they were failing. And I would take a look at the failure, and I'd find out, oh, some service I've never heard of broke. And I had no idea what it did. I had no idea who owned it. And what we found out was this service registry, which was created for the this network rule automation, became this powerful tool to give you insights into who owned various services. And so people immediately latched onto it, and they found uses for it that were far beyond what the targeted use case was, which is this automation from security and infrastructure. So people immediately wanted to start adding fields to this. They're like, okay. I got all this metadata I need about my services. I need to be able to add to it. And guess what happened? Security said no way. This is too critical in this path of us approving these network rules. We can't have you coming in modifying this tool and potentially having some a security goal that gets created. So what happened? People exported the data. They put it into spreadsheets, and this thing, which was, like, this great concept ended up being the same old problem, which is data getting passed around. And it sounds like, Anish, it's kinda similar to your experience. I think the problems you were encountering prior to forming Cortex. I'm curious if you could explain what your journey was like. Yeah. That's exactly right. I and, you know, it's interesting to hear you say how the tool became suddenly so popular with the developer community, and started you started finding all these sorts of use cases for it. I think Uber was very similar in that there is this, you know, decision to very early on in Uber's days to build using microservices. And Uber had a very strong culture of like, we have very strong build culture. And so, you know, Teams were very autonomous and given the freedom to spin up services as quickly as they needed because we wanted to move as quickly as we could. And when you are a small company and you're first starting out and you only have, like, a dozen or so services, it's easy to keep track of all that in your head, and you don't really feel the pain. But when Uber scaled from 200 to 500 to a thousand to 4,000 to 10,000 in just a span of three or four years, you know, suddenly, these services are just impossible to contextualize or understand. And, you know, my favorite thing is seeing services that are named after TV shows or, you know, Game of Thrones characters because engineers love naming services all sorts of crazy things, and suddenly there's an incident. Right? And that's our that's what started to happen a lot at Uber where there was an incident, and 60% of the time we're dealing with the incident, we're we're frantically messaging people on Slack. Do you own this? Who owns this? Okay. The person who owned this left the company six months ago. Who's the new owner? Oh, there isn't an owner. This was kind of, like, the common stream of consciousness path that you would realize it as an engineer, and it was just unsustainable. You know what I mean? And, like, you think about just across all the different incidents, how much time then gets lost or wasted. You know, you need some you need to solve it with some way. And, you know, unfortunately, at at Uber's point, like, while they had built this, like, internal service registry, every team had their own version of things floating around. And then without a owner of it, that became stale very, very quickly. And so I think, like, I think a lot of organizations end up going through something very similar. You know, even from our experience, building Cortex, right, it's it's often, hey. We need to solve this either for a compliance, a regulatory, you know, some some some very important reason, whether it's incident management. But then the, you know, tool becomes incredibly popular because there's the data is so valuable to to every every team, whether it's your SRE platform, security, even, you know, leadership, then, of course, developers. Seems like we're on similar journeys, different places in time. Exactly. Exactly. And, you know, the other interesting thing, you know, is this was six years ago when when we started the company. But even, Jeff, for you, right, this is, you know, you know, close to three, four years ago when when you were starting to see these problems. What's interesting is today with AI and coding assistance and everything that's going on, it's almost like, yes, the, like, the rise of stories oriented architecture has made the the need for an IDP so apparent. But then with with AI, it's like, there's even less context on the engineering team as more and more services get built without needing to write a line of code, when agents are building all your software, it's it's it's interesting to see, like, IDP adoption also be correlated to that. And and it's almost like we're restarting the complexity conversations, but now AI is driving it. So Yeah. I think one of the things that we've seen, a lot of people are saying that AI amplifies the problems that already existed. So you got the same problems that existed about who owns it, how's the service created, vulnerability scanning, security scanning, all of that stuff. But now you're writing so much more of that code because you've got AI to help you. You need those signals. You need to know what is AI written, what is human written. So it just exacerbates the problem. Totally agree. Awesome. And why don't we move on to our next question, which is really around what was that experience like building an IDP from scratch? This was interesting. So I got involved after this initial product got created, and one of the challenges was the contracting team who had built the first, incantation of this product was no longer with the company. So now you had this really critical tool that was kinda hanging on by a maintenance thread. And it was still a problem where you needed to be able to solve these problems. And so what we decided to do at Workday was we're gonna reset, and we're gonna rebuild. And so there was a team that was formed. There were six full time engineers to build the product, three front end, three back end, and it was a great team. And I got pulled into it, and it was a little bit challenging for me because in my role, I wasn't really a developer building tools. I was someone who was connecting systems, and I was putting things together. And one of the things I realized was, and I kind of anticipated this getting involved, it's really hard to build something from scratch. What is the focus that you're gonna take? So this original product that we loved was focused on network security. Well, we had a new focus, which was really the golden path. Paved paths was something that's really challenging. You had twenty, twenty five teams who were involved, and you had 20 steps that you had to follow. And this was Confluence pages and was documented, and it was just hard to follow. So the idea with this application was we're gonna try to follow that paved path and build a question database and have this approval process, but we were missing a lot of the other signals, really, that you had to build. It was slow because there's a lot of stuff that you have to build that you don't think about. Like, what about accessibility? What about the UI accessibility you have to build? What about database tuning? All of these things that don't help me get service ownership. So I kinda wanna jump into my backstage moment. And, you know, Anish, I'm a little bit older than you. There's a movie back in the day with Tom Cruise. It was Jerry Maguire. And there's a great scene in Jerry Maguire where he's gonna change the the sports industry the way that agents work. And he works all weekend. He comes up with this idea, and that's what happened to me. I was convinced I was gonna have a Jerry Maguire moment that I thought we got six full time engineers working on this. I took a look at Backstage. I downloaded it, and I loved it. I was up and running in, like, forty five minutes, and then I started tweaking a little bit of the the the code. And I was able to build some of this question database in about an afternoon. And I'm like, okay. Hang on. We've been spending a couple of months with these developers working on all these things. We've got this company that's built an open source product. Why don't we go that route? So, Anish, I don't work a lot of weekends, but I I built a slide deck, and this is pre AI. Okay? So I didn't have Claude. I didn't have ChatGPT. I built all of these slides by hand. I was convinced that I was just saving the company. Ton of grief, a ton of money. I really pushed. I wanted to use Backstage at Workday. And, well, the six full time engineers pushed back on me. The the engineering manager pushed back on me and said, listen. We already have this plan. We have this investment. We're gonna go this route. So I kept trying to evaluate Backstage while the IDP was being built from this homegrown perspective. And I do have some other learnings that I did find that was part of that, but I'd like to know perhaps about you building an IDP from scratch when you joined Cortex. How did you figure out what you should build first? You know, it's interesting because when we started Cortex, Backstage and and Spotted Hat, I mean, that there was no Backstage. And so we were just calling ourselves a service catalog. And then, you know, Backstage came around. And to your point, it was, you know, seeing the success that Spotify had internally, you know, rolling out Backstage and all the methodology that they had around how important it was to systematize and actually have a central system of record that you can point to when you're looking at applications or ownership. Like, all of that made complete sense and was in line with why we originally started Cortex, which was to understand and and operate your microservices. And so when Backstage came out, it was like this moment for us where we realized that, well, this is, like, this is a problem that, you know, a company like Spotify has invested so much time into, and it made sense for us to, you know, take on the internal development portal name. But what was interesting is when, you know, we started talking to other organizations who were thinking about IDPs or thinking about Backstage, you know, there were very central reasons that would be interested in in a product like Backstage. Know, to your experience, right, having that central view to look up ownership and look up applications and having that framework to be able to, you know, take something Spotify has and and and just reuse it to immediately start contextualizing all that information, it makes it makes perfect sense. But what we would find with sometimes organizations who started doing that is exactly your experience. Right? You we get your data inside, and then suddenly, everyone is trying to integrate with it. Everyone wants to use it. There's a reason why the data becomes so valuable. Right? It's it's like so many use cases from looking up ownership during an incident to wanting a centralized place to be able to see this information for, like, security migrations or things like that. But what about RBAC? What about custom views? What about all the other central configurations? And I think the the long tail of what ends up happening when you take on something like Backstage, it's hard to sometimes fully understand when you're starting the project. And that was what our experience was as well, right, where I think Backstage is one of the, you know, best things that that happened to the market of IDPs. And and, obviously, like, so much credit goes to them to evangelizing it and for trying and quickly seeing what the value could be. You know, it's often an amazing place to start. But then what really clicked for us was, okay. You have all this catalog of data. You have all this information that you're putting inside, like, ownership and connecting all your integrations, you know, building that single pane of glass. But what really clicked for us is when we started asking organizations, well, what what are you doing to keep this data up to date, or what are you doing to operationalize this data? And that's where we realized that, okay. Well, having the service catalog is good and it's useful, but what really drives ROI and actually drives culture change, which is, you know, a side effect of an IDP, is how do you take that data and use it in in applications and and best practices? And so, for example, the first product that we built, that elevated, I think, the IDP was was scorecards. Right? And scorecards was a way to enforce standards and best practices, and it really, really resonated with the SRE and platform teams that we were talking to who were interested in Backstage because it was it, you know, it it hit this core pain point that a lot of these teams have around enforcing, standards. And and not only enforcing standards, at at, like, the leadership level, but how do I get developers to understand the quality of their services and and actually take change? And that's just something that Backstage had never approached or wasn't really a focus on. Right? Because I think Backstage is very, very much a developer experience platform. And so for our our experience, it was like, yeah, building building the catalog and building those experiences, but then scorecards, I think, is what really helped us then, like, elevate and and and uplift the whole category in general. Which is interesting because some of the stuff that we were trying to build from scratch at Workday didn't even touch on that. So we were honing in on one really small piece of that overall engineering ecosystem that you see. I I think that we probably would have struggled if we continued down that path. And I actually I had to step back a little bit and realize that even though I loved Backstage, it probably wasn't gonna work long term. So I did have a side project where I continued to say say to myself, you know what? I'm gonna push forward to see what we can do with Backstage. And here's one of the things that I I think people will run into, and I'll be curious from the audience. For people who are kicking the tires, let's say, if they've run into something similar, you can get tripped a little bit by that initial download and, creation of your first project. It's like an endorphin rush. You're like, okay. I've solved it. So it only take me half an hour, you know, an hour on a Friday. What if you need to operationalize that? So I started to look into that. And so number one, I found out there's policy around contributing to open source projects. So I had to make sure that my team had training. I had to make sure that I was registering user accounts so that I would be able to make additions to the open source project that they put together. Alright. Well, I don't wanna write a lot of code because I wanna keep things simple. What if I just accept what they give, and we'll go from there? I ran into this problem. So if you're gonna install and use third party applications, a lot of companies wanna have strict security policy around that. They're gonna ingest that into their own repository manager before you can install. And what do you do before you ingest it? You run a security scan. So this was an eye opener for me. It failed the security scan the first time I tried to get it involved and pushed into the local Artifactory instance. And I couldn't believe it. Like, why like, don't they have a build process? And so I reached out to them. And, support was via a Discord channel. And I realized, oh my gosh. I now need to get support with a company that owes me nothing because they've given me software for free. There's no SLA. And I'm saying, hey. I'm blocked because I can't get the security scan to work at Workday. Well, they were using a different scan tool, so they were finding different vulnerabilities, obviously, because they had an automated build process. And so that slowed me down. And then there was the matter of, okay. Big deal, Jeff. You're running this on your laptop. What if you need to run it in infrastructure that's got high availability? You got disaster recovery. You got backups. You got all of this stuff that is just slowing me down from wanting to get the signals that I had. So I still love Backstage, to be honest. I just think it takes a lot of time, effort, and manpower to run something that's free. Completely agree. Completely agree. And, you know, the other interesting thing that I was thinking about while you're explaining explaining this, and this is, a conversation I have with a lot of executives who have built on Backstage for years at some point. Right? I mean, now IDPs have existed for a while, and a lot of the time I spend every quarter is talking to executives who have invested a lot of time and resources into Backstage. And I would say the number one thing that I hear after a lot of organizations have spent, you know, the time and energy, and, you know, maybe sometimes three or four years in getting a lot of the plumbing and infrastructure up, is actually, you know, the executive is left wondering, like, what is the actual business case here that we're trying to solve for? Sometimes in the process of building and investing so much time in in all the maintenance, I think we forget that, well, there's an opportunity cost here. At the same time, the all the investment that we're making into this platform, we also have to think about, well, what is it actually doing to drive business results and business outcomes? And, like, I think that can be a very difficult conversation sometimes with leadership. And, well, sometimes I've even found, you know, sometimes leadership changes and having to rejustify all this energy and the resources and time, it can it can be difficult, honestly. And I think that's the other thing that, you know, obviously, as an organization who adopts Backstage, I think you you have to really be thinking that product and business mindset because it is gonna be an investment. So you'll be be able if the product isn't helping you justify that as a as a team, you you have to be sure you're thinking about about it because there's there's always a trade off in in any in your organization. As I kept thinking about it and the other things I would have to do, performance tuning, database access, database tuning, I started thinking, well, well, my Jerry Maguire moment, I didn't know if I could recall all the, PowerPoint slides that I had sent out because I started thinking, it's kind of ironic that you're implementing this app so that you can track all the complexities involved in building software. And now you've got all those complexities in this app that you're trying to deploy. And so one of the things that I realized is I didn't want to spend all of that time and energy going into the creation and the maintenance of that app Because I'm really passionate about putting together software that works, highly available. I don't wanna let my users down who are using that software, and I realized I would be spending all of my time and energy trying to make sure that that app had been deployed accurately, wisely with backups, with disaster recovery, and I wouldn't be able to get the signals that I was interested in. So I still am looking for my Jerry Maguire moment, Anish, but at least I attempted it. Yeah. Makes total sense. Why don't we go to the next question really focused around and I know we touched on this a lot in in the previous slide as well, but, you know, obviously, your team was looking at building something on their own. And we see this today at Cortex as well. Right? I mean, obviously, you have Backstage as an open source framework that can make it easy to spin up things. But then sometimes companies will just say, hey. We're gonna do something just totally on our own as well. Like, you know, what made you look at Backstage as a solution? I think, for me, it was the source of least friction to get started. So I was getting a little bit frustrated at the amount of time it took to build an application from scratch. I like to have immediate gratification. I wanna have something up and running. I wanna get my hands on it. I wanna access the API. I wanna start loading data. And that's what caused me to go to Backstage. I wanted to take a look at something that I could get up and running faster. And one of things that's interesting for me since I joined Cortex is I see a lot of companies will do this, and they'll have pockets of Backstage running. I think they run into the same thing that I ran into, which is, listen, I need a solution. I need it now. I can't go through all of these layers of bureaucracy to try to get something that I need. We've got this little server in the corner. We got a little cloud account. We got a few dollars on it. We're gonna get this thing up and running. And it's been interesting for me to see that because it's so dangerous to have something that starts to work, but it's working in a small pocket. Now you need to push it up through the organization because you say, hey. We've got this great solution. And what do you run into? You run into these other tribes who are doing the same thing, and you've got these little pockets of solutions that are going. And now you kinda have to work your way up that chain. So I think for me, that was something to be on the lookout for. Again, I'd love to hear from our audience if if they've seen this when they were kicking the tires. Did they find out that they had other organizations that were taking a look at these point solutions? But curious, Anish, as you've talked to customers, what do you hear as, people are starting to look at Cortex? What are they telling me about some of the pain points they've seen with their initial kicking of the tires with Backstage? Yeah. It's a it's a really good question. And you know what? I think it can vary. Right? I think it can vary depending on the team that is starting to implement Backstage to the size of the organization to the journey that they're all all already taking on their kind of modernization efforts. You know? I I say that there's a few themes that are very, very common that would, I think, invoke someone to look at Backstage in in in today's world. Right? I think, like, the first is it's often around liability or incident management. You know, there's a big incident, and a lot of the time, organizations will come to the realization that they don't have a good understanding of service ownership. Right? And Backstage, because of the catalog and because I mean, IDPs in general, right, one of the core value props is service ownership. And so I think you can kind of get people excited by the idea of having this, like, common service registry that they can look up information in. I think what our key insight has been for a lot of those organizations has been, yes, the catalog is interesting, and it obviously provides that benefit. But keeping that information up to date and being able to then use that ownership to actually get developers to invest in the IDP, I think a lot of people don't think about that aspect of things. And, you know, actually, the like, let let's be honest with what developers do on a daily basis. Right? Like, as a developer, I spend most of my time in my IDE, even more so now with coding assistance. And maybe sometimes I'll go to GitHub or maybe sometimes I'll go to my on call tool when I get paged. But for the vast majority of my time, I'm spending it in my IDE, or it's, you know you know, cursor or or whatever tool that you Cloud Code, you know, whatever whatever you wanna use. And the reality is for a lot of organizations, they sometimes have this idea that, okay. Backstage is gonna be, like, the first place my developers go to every single morning. They're gonna start and end their day in the IDP. And, honestly, when we started Cortex, that was some of the, you know, inspiration that we had too that, you know, your developer portal would be like this and, like, you know, magic place where developers are gonna spend a lot of their time in. The reality is, and this is true for any IDP today, is that you're only going to your IDP if you're really trying to solve a very specific pain point. And that pain point is typically if you're a developer, it's like looking up ownership. And if you're using Backstage at least, it's like looking up ownership or looking up applications. But even then, the the muscle memory of a developer actually starting to integrate a new tool, like an IDP, into their into their daily workflow is it's a cultural problem. It's not just a product or technology problem. Right? And and just basic basic things about developers. Right? Like, you they're gonna use the tools that benefit them the most. And so this is something that I think a lot of organizations don't actually internalize as a challenge at Backstage is that, okay. Yeah. I could invest years into getting all the data in there, but developers might still not use it because they haven't built any muscles or or memory or, like, incentive to remember that, hey. I have to log in to Backstage and look up this information. And so how do we think about that at Cortex? Because we realized this super early on, and it's often a conversation to have with Backstage customers. And what I say is, like, well, that's why it's not just having the data. It's being able to use that data in critical moments that benefit developers themselves. So, for example, one of the things that we released recently that's been a huge hit has been our MCP server. Right? And it's actually you know, any of the engineers can access all the data inside of Cortex or in scorecards just in the same place they're in their coding assistant in. And for some for a lot of our customers who've adopted MCP, you know, 90% of the time, developers are not even logging in to Cortex anymore. And that's actually a good thing because the whole point is that we're removing friction from developers' lives. We're letting them focus on building software for the business. I don't even want them to need to log in to a portal to be able to access information or get the value or receive a notification. I guess all this happen in the same place they were. And I think, like, from a product philosophy standpoint, this is actually something we've kind of maybe diverged a little bit with Backstage because, you know, yes, you know, Cortex users will build plug ins and custom internal tools, and maybe that's a reason to go back and workflows, of course. But even those things can be the data and the value can come directly where you work. So, yeah, it's just been interesting to see, like, the market evolve and even the product philosophy around, like, well, is it a developer experience platform or or or really just trying to help developers build higher quality software, which is, I think, where where our stance on it is. Yeah. There's couple, interesting comments and questions, I think, in the the q and a, and one of them comes from Pat who says, knowing what you know now about the maintenance of Backstage, if you're gonna start today, would you build it and hire six people? Well, first of it wasn't my idea to hire six people. I probably wouldn't want to do that, and I wouldn't do it today. The thing that I really wanna do is I wanna invest my time in the solutions directly in the platform with as little friction as possible to get them going. So there's another comment from a user talking about the power that you do have in Backstage to build plug ins and change it in any way you want. I completely agree with that. And the thing is I think you have to balance out where is my investment of time gonna come. Because those plug ins, that customized view that you want, you can definitely invest there. I'd rather do configuration. I wanna get some stuff in very easily through automated integrations, maybe a little bit of YAML and JSON. And so, Pat, to answer your question, my thought is I wanna use an IDP where maybe I only need one full time employee who can manage that whole ecosystem because someone else is dealing with all of that other infrastructure. Nish, let's go to the next question. Awesome. So looks like we have another poll. Wanted to get a sense of what, you know, the audience's biggest challenge with Backstage is today. So we have some context, and and we can talk about that as well. So we have a few options here. Could be all of the above or or or none of them, but we'd love to get a sense from everyone, you know, what they're focused on. Do we have any game show music we can run while we're waiting on the poll? That'd be nice. You can try singing. Oh, okay. No. No. Because I won't get invited back, Anish. Okay. It looks like developer option is a winner so far. Maintenance overhead. Yep. Yeah. I think I definitely saw that on the customization side. So when I first installed Backstage, I told you I was up and running in about an hour, and then I remember doing an upgrade. I think I'd probably modified a UI screen or or did something, and so I wanted to upgrade to the next version of Backstage. And all of a sudden, I saw these source files were broken. And I'm I'm not a TypeScript developer, Anish. And I saw these stack traces. I saw all these things that were broken, and I thought, oh, no. Sure. I was up and running in an hour, but how am I gonna maintain this thing? And so I definitely saw that maintainability, the customization problem very early on even after just a couple of weeks of trying to run the app. And so that's why I was very eager to to find a SaaS provider, to find someone who would deal with all of those things for me in a a place where I could probably run and not have to customize at all if I didn't want to, but have the ability to customize if I wanted to. And I think that's kind of the the thing that I've been looking for as someone who implements an IDP is that I wanna have a solution that is somewhat opinionated so I can get up and running out of the box right away, very similar to my Backstage experience. But I also wanna have the ability, if I need to, to kinda go that extra mile, whether it's with customized plug ins and to do that thing. But I personally have a very conservative approach when it comes to that because every line of code that's written has to be maintained. And, sure, I can get clawed to take a look at it, but it's still something that might break. And so even if you've got an AI assistant that's helping you, I think we talked about this a little bit earlier, AI is just gonna amplify the stuff that's gonna happen. So if I start writing a ton of plug ins and maybe there's some upgrade to a new version of who knows what dependency that I've got in my stack and it breaks those, I gotta fix them. I know I can get AI to fix them, but I still gotta give it the prompts. I gotta run it. I gotta push it. I gotta have some kind of a test instance. So that's the balance that I personally wanna take. And so I just wanted to echo that complexity and maintenance problem with something I ran into myself. Yeah. It makes complete sense. And, you know, I it's interesting to see, you know, developer adoption is one of the big challenges. It's it's it's not a surprise. I I I think that it's it's interesting because even I think the the head of Backstage in one of the interviews they gave a couple years ago said that the average adoption rate is around, like, 10% for developers with Backstage. And I and I honestly, I just think that that number has probably gone down over the over the last, few years even just as, like, developers' time has become more and more allocated to cloud code and the AI assistance and and all of that because it's just like, that's where developers live live today. And and being able to meet developers where they work and use the I like, the data and the IDP to kinda power these experiences that help developers inform how to build quality software without them needing to, like, learn a totally new technology, I do feel that that's, like, so critically important when you're thinking about IEPs in general. And that's really been, I think, the the approach that we've been taking and seeing seeing some success far in terms of, like, getting developers really, really excited about the developer portal. Love that. Well, I think what is the key, you think, to getting that developer adoption? Because it's not unique to Backstage. You must face it, on a regular basis when you're talking to leaders in the industry. What do you think the keys are to getting developers to adopt? Yeah. Absolutely. And I think this is useful, by way, even, you know, if if like, if, let's say, you know, the the goal of you're here today is just to get even adoption of Backstage. I think everyone here who's looked in IDPs, it's very, very easy. You quickly understand that IDPs have, like, 50 different use cases if you really, like, spread everything out across the catalog and workflows and, scorecards if you've built or or or are trying to use those. And that can be very, very overwhelming for developers, especially when you roll out. Like, hey. Okay. We have this amazing platform. Here you go. Typically, it doesn't work. Right? I think what we've seen success in is taking very specific use cases and aligning the rollout of your IDP with those use cases. And they can be either short term or kind of long term initiatives that you have. A good example of this is maybe there's a migration that you're running, you know, like a Kubernetes migration, for example, or you're migrating CI tools or something. You know, for a lot of developers, sometimes, you know, you, as a developer, are expected to upgrade your services or manage that, or maybe there's a spreadsheet floating around that a developer has to, like, go in and manually update. You know, if you're able to attach the world of your IDP to making that process completely seamless and automated, and then, you know, you're able to track all of that and developer now, it's like, wow. I I got in I was able to see success and and get all this visibility into into my work without necessarily having to manually go and update everything. Like, those little wins add up, and they gain the trust of the engineering organization. And then you're able to kind of hopefully link it to kind of these broader initiatives you have at the leadership level, whether it's, you know, improving the driving on MTTR or improving deploy frequency. You know, you have, like, these larger metrics that you care about. And so I would just say that having that, like like, business mindset when you're rolling out your IDP, both to be able to justify it to leadership, but then also for developer, you really think about, like, their day to day. What are the things that are pain like, the most pain point for for them that I think I can solve in the first three to six months with this with the IDP, I think you you really have to kind of nail nail that when you're rolling it out. Anish, my wife claims that I only ask questions because I wanna answer them myself. And so she's actually right. So I wanna answer that question myself because I I echo a lot of the same things that you've said. The. thing that is a trap that I'd let people know about when you think about implementing your IDP, you know you got all this uncatalog data, and your inclination is to load it all in at once. And one of the things that you talked about was use cases, and I've seen that myself working with customers is that you really have to attach business pain or friction into the way that you adopt your IDP, way that you populate the catalog. Because if you say, hey, everybody. A new task for you. I know you've already got a 100 or so that you're responsible for. Now you gotta get your data up to date, and they don't see the benefit of it. You're gonna lose that word-of-mouth advertising. You're gonna lose that excitement that exists within your community. And so there's really two ways to go about this. One is you're gonna solve organizational pain. And the individual doesn't always wanna contribute to that. They got their own stuff that they're dealing with. But if you can also take a look at individual developer pain that your IDP can solve, that's where you're gonna get that adoption. So that's one of the things I'd really recommend that you do is fish out, find where you've got those friction points, where you've got that business pain, and lean in in your IDP in the way that you're gonna roll it out to address those things. That's a really good point. Makes total, sense. probably a question for you that just came in from the audience. What does Cortex do differently to facilitate developer adoption? Yeah. Absolutely. So there's two aspects to it. Right? Like, there's the actually getting your data in and building the catalog and making sense of ownership. Right? And then there's the actual rollout of your IDP and driving kind of that developer culture change and behavior. And Cortex has you know, if I could if like, over the last few years, I think we've done a a a really great job kind of focusing and building the product for both of those. And so, for example, in the integration setup, you know, we just have a ton of automation and have built a lot of, like, actually, ML models that are able to really predict things like service ownership. And so, for example, you can import a thousand repos inside of Cortex, and we can actually tell you based on different heuristics, like top contributors, the people reviewing the code, other integrations that you've set up. We can actually predict the team that owns that service. And I'm not kidding. We've seen onboarding times just because of that single feature drop months. And and the benefit of that and actually just taking a step back, if the data in your IDP is not accurate or doesn't make sense, if a developer logs in and they don't see their information or it's inaccurate, it's no better than a spreadsheet. And this is actually really, really critical and I think something we've learned the hard way, to be honest with you. And so we've just built a ton of automation into it so that your data is up to date, and you can get your data inside as quickly as possible. And and so that, you know, we have over, I think, 80 different supported vendor integrations now that we constantly update and manage for our customers. We have a full time integration team that manages that as well. So just a lot of investment in that first piece, which is getting your data in and making it all kind of accurate and and represented the right way. And then there's a second piece of it. Okay. Well, how do I now get developers interested in in using the product and actually seeing value? I think there's a few different things that we found have worked really well. The first is what I was talking about earlier, which is take ongoing initiatives that you have, whether it's package security migrations or a production readiness checklist that you're really trying to enforce. You know, these, like, expectations that developers have to build high quality services. I think a lot of developers want to build high quality software, but they just don't have visibility into, like, what are the things that are actually be focused on or the areas of risk from, you know, the services that I own. And Cortex has built a really powerful product called scorecards that actually lets you enforce those standards. And for a developer, you know, they get these really sweet reports that tell them exactly how their services are doing. And the thing that we do that I really love and our customers love as well is we gamify the whole thing. And so our scorecards allow you to build levels like bronze, silver, gold. Engineers love seeing their services at the gold level. We even let you put, like, GitHub badges. Like, we've seen engineers put GitHub badges saying, like, hey. My service is at the highest level. People bring it up in, like, stand up or you know, like, from a company standpoint, being able to show that, hey. We have, you know, these 15 tier one services that are performing really, really poorly on our production readiness scorecard. And as an organization over the last quarter, we are able to take these services from bronze, bring them to gold. Our MTTR dropped 40% because we're able to do that. By the these are real stats that we see with our customer base. Right? That story and that validation, it's really, really powerful, and it actually kind of empowers developers to understand that when I care about reliability, when I care about quality, it really improves the business and, like, improves life for our customers. And, you know, there are lot of stories that you can tell from that. And so Cortex helps facilitate all of that from the scorecard management to communicating with developers. A lot of our customers will sometimes call us the TPM in a box, which I love. You know, we'll manage that whole process for you. And then for developers, right, it's not like I have to log in and manage or keep all that information in my head. You know, we'll we'll communicate with them through Jira tickets, through through notifications on Slack. And then finally, you have your MCP server, which I think for most developers, honestly, is the preferred way they use Cortex. They just ask questions in English to, you know, to their quoting assistant and get answers instantaneously. And so all of those things, I think, seamlessly integrate Cortex into a developer and into a engineering team. And it's like, I don't have to learn a new way of doing something. It's like almost like Cortex just meets me where I work, and I think that's really critical. Anish, I get the sense that you're kinda passionate about this topic with that answer. True. It's true. That's why I started this. Yeah. So we better move on, I think, to the next question, because I wanna get a chance to share this story. Tell me about your spreadsheet moment. This one was pretty easy for me. There was, we were on our first, rollout, which was that original service registry with the network rules. And a team came by and said, hey. We gotta go through FedRAMP compliance. We wanna know all services who are FedRAMP compliant. Can we get an update into that tool? Nope. You can't. And I was thinking, oh my gosh. I'm just trying to get one field. I'm trying to get one field in, and the team said we're looking at about six weeks, you know, to be able to take a look at that. And so what'd they do? They did an export. Out of that, they started creating a spreadsheet, and it just it broke my heart, Anish. It really broke my heart. And I remember learning about Cortex having something called custom metadata. It's a real simple feature. It's really easy to extend entities. You don't have to go through any kind of development process. You're just able to customize and add additional information as you need it. You don't have to go through an approval process. You add it. You talked about scorecards, field measures, something like that. For me, that was my spreadsheet moment. I need an easy way not only to get data in initially, but as times change and my company evolves and it takes on new projects, I need it to be very easy to adapt and then to adapt to new policies. That makes complete sense. I I I'm curious, like, who, like, who is responsible for keeping track of the spreadsheet at Workday? There's an individual. He just he. owned it, and he had to pass it around. And you had to make sure he wasn't on PTO, and then you had to make sure it was a v one, v two, v three of that thing that was going around. course. So, yeah, I think anybody who's gone through the the spreadsheet debacle knows about it. I know that you've often shared a slide where you just have all these blank cells where you don't have owners and all of those things that you talked about with some of the things you encountered at Uber. Totally. Yeah. Completely agree. I know we have a little like, less than fifteen minutes, so maybe, we'll move on to the next question. So at what point did you decide to start building? I know you touched on this a little bit, but This was really interesting for me because it wasn't necessarily my decision. I wasn't the leader. And I was part of a team, and there had been a team decision. And I was, like, the lone dissenter, which was really difficult. I think I decided early on I have a buy over build personality that has evolved over time. I think when I was younger, I used to love writing code. It was kinda like my own badge. Like, yeah. I've written tons of code. And then I got a little bit older, I realized I gotta maintain that code. Oh, that code broke. I gotta update that code. And so for me, I just didn't wanna do that investment. So I it was very interesting to be part of a team where I wanted to be supportive of the idea, wanted to be supportive of the project. Team was great. I really loved working with them, but I just felt like it was the wrong decision. And so I mentioned that I had tried to push backstage and try to build something ourself. And, we were lucky that a new leader came in, and this is another thing you have to be on the lookout for is that you might have an idea. Maybe you're a build over buy culture. What if leadership changes? Are they gonna sit think the same way? Are they gonna still hold on to the same solutions that you built in Backstage? And so, for me, this leader came in and said, let's just do a reevaluation. Let's see if we can move a little bit faster. And so I was grateful to get that opportunity to go back to the market and reevaluate. So I decided early on, I didn't want to do this, but I think it's important to be a team player and go along with what you're building. But I was really happy to then have leadership step in and say, you know what? I think you might be right. Let's go take a look at a a package solution. Yeah. And, you know, I I think you're being here at Cortex, you speak to so many technical teams and even leaders who sometimes have invested a significant amount of time in Backstage, you know, maybe they've reset and passed. And, I'm curious. You know, maybe there's someone in the audience today who has put in that time, and it's almost like this this sunk cost fallacy moment. But what would you say to them? Like, hey. I've invested two years. Like, how should I think about that? That's a tough one. I have worked with customers who have put together some really powerful homegrown solutions. And I'm I'm thinking of one in particular where they told us we love what we built. Our users love it, but we're spending 85% of our time on maintenance. We only have, like, 15% headway to do new feature development. You think about it. Right? Every line of code, you have to update. You have to maintain it. And so the more features they built, the more the maintenance cost went up. So. they were building a more and more powerful solution, but it was slowing down their development. And so I think you just have to look at the macro picture. What is this gonna look like three years from now when I don't even know the next thing that's gonna be developed? This company was building several years ago before the AI explosion. So how do you then react to that when you've got this massive code base? So I think it's the type of thing where you just wanna make sure that you're set for the future. And even I, I think, was doing a great job of that when I was thinking, yeah. I'm gonna go with Backstage as opposed to building something myself. I didn't really extrapolate out three to five years on what's the investment now, and what's the investment gonna be long term. And so if you have data that you can export and get it into a solution that you might look at, might be Cortex, might be something else, think about how quickly you might be able to move to that new platform, and what's the overall gain you'll see in the long run. Awesome. Thank you for sharing that. It makes makes complete sense. Awesome. And I think we're this Andrea, of our last questions, you know, what patterns are you seeing across companies migrating from Backstage? I think it's a lot of the same stuff we experienced in the poll that we asked the users today. It's upgrade complexity. It's maintenance complexity, plug in complexity. It's complexity if you really wanna boil. it down. I think that customers are looking for something that's kinda simple. When you have to explain your ecosystem to a leader, can you explain it very easily? Can you show them what the costs are? Does it make sense? And I think it gets tougher and tougher the deeper you get involved. And so it just it's like any other complex solution you might create yourself. There's all these tendrils. Right? You got all these integrations, Yeah. downstream downstream consumers, And it just gets harder to ever walk away from that kind of a thing because of all of the customizations really that you put on top of it. Upgrades become really difficult. Dependency on third party plug ins, what happens when that developer no longer builds that thing, and you have to take it over, and you have to think about those things. So it's interesting. Like, in anything else in computer science and software, in this industry, there's trade offs. Right? So the the configuration and the, ability to customize that you might really like initially might be a pain point down the road. So I think it's those things that's you know, we were happy initially, but as things have gotten more complex, as we've been doing more investment, it's been more difficult to maintain it. So we wanna look for something simpler. What about. you? Complete. When you talk when you when you talk to leaders, what are you hearing about when they are trying to get off of Backstage? What are they telling you? Yeah. I would say that developer adoption I mean, every everything you mentioned is is 100% spot on, but I'd developer adoption is, like, usually, one of the conversations that we're often having. Developer adoption and then also just, you know, you sometimes hit your limits on all the value that you are seeing with Backstage, and it's gonna require ultimately building and building in a product like scorecards or really extending the functionality in a lot of different ways. And suddenly that becomes, you know, from a team of three or four people who are managing it to now you need to be, you know, thinking about, like, ten, fifteen. You need a product manager on the team. You might need a designer on the team. Now you have, like, a full fledged team that's just kinda managing this. And, you know, at at some point, I think that trade off around, you know, do I go with the commercial product? Or you know? And, obviously, like, this is our full time job. This is you know, we have, you know, 50 plus engineers who are building and adding features to our platform every day. I think that's kind of the trade off that I think a lot of engineering leaders are working through right now. And so but, you know, oftentimes, when we meet anyone who is really interested in Cortex, you know, we actually do encourage them to trial Backstage. And a lot of people like, most of our customers have. Right? Like, it is great to get something quickly spun up. Like, Jeff, you said mentioned in your experience. But then I think having that kind of product mindset around, well, what in a year from now, if everything was successful, what is this IDP? What is this platform doing for our engineering organization? And I think what you'll quickly find is, like, that road map of things and all kind of the aspirations you have, balancing that with, I think, like, yeah, like, a commercial offering. I think that's that trade off and and evaluation that we usually end up seeing. I think it's usually, like, a bottom up approach with Backstage. Right? You get a couple technical leaders that are. interested in it. They build something, they wanna push it up versus I don't think we often see leadership saying, hey. We need a solution. Let's build out a massive Backstage ecosystem. Yeah. Completely agree. Completely agree. see if let's see if we can get a couple more questions in, Denise. Let's do it. So I think the next slide is, yeah. So, I mean, I've kind of talked a lot about Cortex, already, but just kind of briefly chatting about it again. You know, I I understand for a lot of organizations, we anyway, I it's like, I've invested a ton of time back to it. All my data's in here. What does migration look like? Well well, the good news is, you know, we do this every single month, and we've built systems that allow us to pretty much migrate all of your data in less than an hour to Cortex. So all of your systems, all of the, you know, relationships you've built in when the the dependencies, all of those things, all the integrations, are pretty much just like we have a plug in that basically can migrate all of your data from Backstage to Cortex. And then we have our own plug in architecture as well. So, you know, a lot of customers for example, we recently migrated Canva from Backstage to Cortex. You know, they were able to, within three months, migrate all their custom plug ins that they built inside of Cortex. And that's, you know, much less time to actually getting the data in there. And then they were starting to be able to use, like, part you know, things like scorecards and and and kind of build on top of all that data itself. And then, of course, you know, our team is there to help. We have our amazing, amazing post sales team. And and by the way, the best part of all this is you get to talk to Jeff, and he's gonna help you get get your data in. And, you know, he's he's the expert into this. But, yeah, you know, this is, you know, this is really care deeply about this work. I think it's it's it's so important, especially in in today's world where more and more code is is being written by AI. I think every leader is thinking about quality, is thinking about how do I make sure that as, you know, even nontechnical people start, in my organization, start getting access to coding assistance. How do we make sure that quality and reliability and, operational maturity stays excellent? And I think that we've just built a lot of enhancements and and unique features to Cortex that that drive that and make that a possibility. And so, you know, if you're if you're if you're just trying out Backstage or if you tried it for a while, we'd love for you to just even take a look on, like, what it looks like with your data. We're definitely here to help. Love that. Maybe time for one more question, Anish. I'm just taking a look at the a question about Backstage being very powerful to customize. How is Cortex customizable comparing with Backstage? You wanna take a first stab at that? Yeah. Absolutely. So this is something we've invested a lot of time in, right, all all the way from the data model being, very generic, so you're able to build any kind of relationships you want, import any type of entity. You know, Cortex is as flexible in terms of, like, getting the data inside of the product. And, of course, I've talked about the automation we've built that's different than Backstage. However, you know, Cortex also has a plug in ecosystem that allows you to build and actually build on top of the platform. And so, you know, I would say probably a 100% of our customers who migrated from Backstage have built their own custom plug ins. And so that really allows you to get kind of the benefit of automation and, you know, not being having to maintain the data. But then, yeah, there's custom things that are unique to my organization that I wanna make, you know, unique to my developer portal, and Cortex gives you that flexibility end to end, which I think is really cool. And I'll add to that. One of the things I like about customizing Cortex is that you can do it through the API, through YAML descriptors, and not have to change code. I think I mentioned a little bit that I'm conservative. I don't wanna write a lot of code that has to be maintained. So I don't often push for plug ins myself because even though they're powerful, then you have to maintain them. So I I would prefer to do configuration over actually building code, and that's where I see that it's powerful that you can extend it. So I think that we're at time, Anish. I would just like to say thank you to everybody who, tuned in today. Looking forward to continuing the conversation. Please reach out to either me or Anish. I love talking about IDPs. Happy to talk about catalogs, challenges, successes all the way around. And maybe final words from you, Anish. Yeah. I just wanna echo that. Thank you so much for taking the time. If you wanna talk to customers who have done this migration, we are more than happy to make that happen. And then Jeff is also available. If you wanna just chat with him, you could book a one on one session with him. We also have in our in our docs section here, I think in the in the webinar area, you can get a Cortex compared to Backstage flyer that you can look at. But, yeah, I just wanna say thank you so much, and we will see you at the next webinar, whenever it is. Thanks, everyone. Bye. Thank you.