What's going on? Everybody? Welcome to another episode of Adventures and DevOps. I'm actually flying solo today. Warren and Jillian both had conflicts and couldn't be here for the recording, but I do have the CTO and co founder of Cortexshta Ganesh. How are you doing? Great? Load to hear? Awesome man, looking forward to it. So Cortex is a platform engineering tool, right, yes, we are an internal developmore right on cool? So what decisions did you make in your life that decided that you needed to create an internal developer portal? You know, it's it's pretty funny actually, So I actually a lot of things. I think, let up this and maybe a little bit of a ramble here. So I went to I went to UC San Diego, and one of my roommates in college introduced me to another friend of his from high school who is now my co founder and CEO, and another one is my co founder in chief architect at Cortex. So didn't know these guys, and I met him in met him in undergrad. I graduated in my undergrad a year early, and I promise this will be all relevant in just a few minutes. I graduated undergrad a year early started working at lend Up, and it just so happened to work out that they were pulling the first service out of the monolith at the time. So I got to join the team that's pulling the first service in the monolith. So timing was impeccable. If I joined the year later, if I graduated on time, I would maybe have been on a different team. I wouldn't have seen that experience. And so it worked out that I was on this team as they were pulling out the first the first service, and a lot of the learnings that came from that ended up being I guess really stemming from pain, like a lot of spreadsheets, a lot of getting Paige at two am and it's some Game of Thrones character that you have no idea what this service does and you're like digging through confliments and whatnot. And for its worth, like we'd invested quite a bit in all the tooling and the infrastructure and all the stuff, and so it was like generally pretty decent. It wasn't even like we had, you know, ignored the necessary investments for MICROSOFCE architecture, but we had all this pain and a niche was working at Uber at the time with my other co founder and CEO, and we were just grabbing a beer and we were talking about like just stuff of work, and I remember asking him like, hey, you're a uber, Like you guys have so many micro services. How do you solve this, Like how do you keep track of owners? And he's like, dude, you just slack people and you just hope for the best. And so all that to say that if I hadn't roomed with the right person in college, and if I hadn't met these two guys and they weren't working at Uber and Toyo, and I hadn't joined the team that I was working on the first micro service coming out of the monolith. Because I joined at the right time, maybe Quartex wouldn't have happened. And so a lot of things we had to go right for for us to land on this idea. Maybe maybe I would have ended there in a different path, but you know, things, things work out for the best. So I promise it would all come together, and I hoped it. Yeah, for sure, that's cool. Like there was in the in the nineties, there was this show on PBS called Connections, and I can't remember the host's name. But he would tell like a similar story where every episode was like this series of events over like two hundred years and how it led to like the invention of some something that just changed civilization and it's like, wow, that's that was a whole lot of steps that could have steered that off course. Oh my god, yeah, one hundred percent. I do reasgually remember that show. Cool. So, so what are the big pain points that an internal developer platform, like for someone who doesn't have an IDP, what are the things in their life that would make them say, oh wow, that's what that would do. Yeah. So I think our thinking on this has actually changed in the last like twelve to eighteen months, and we'll kind of walk you through why then. When we first started Cortex, it was really just I don't know what services we have, ownership of these things is really broken. Let me create a system that we can put all this stuff into that when there's an incident or something, I know where to go. And I think over the last four years it's really changed quite a bit. And I think over the last eighteen months, what we believe is if you have any sort of initiative around engineering excellence, you should be thinking about an IDP and injuring excellence is a broad phrase, but we define it as the investment in kind of high performance injuring foundations to enable business outcomes. So when you think about any organizations that's investing in security or reliability practices or platform practices or making their systems more efficient or trying to move faster, those are usually like injuring foundations, Like those are things like if you do these things right, you will hopefully be able to build more features better and deliver in more innovation or you know, cost productions or whatever those things are. And I think what's interesting is a lot of organizations have had teams pop up around these kind of goals. And so you have like SR teams that own sec owned reliability, and you have security teams own security. And if you squint an organization, you kind of see like injuring excellence as these set of teams that don't really own product outcomes but own kind of engineering outcomes. And those happen to be our best stakeholders, like they're the ones that use the IDP in order to drive these outcomes. And so if you have a kind of a service oriented architecture or some sort of complex software ecosystem and you are looking to invest in these kind of engineering outcomes, then how can you do that without a system that is designed for that use case? And like the example that I always give is like a CRM, like any sales self respecting sales organization like would not be operating out of a spreadsheet or a bunch of confluence pages. Like imagine you went to a VP of sales and you're like, and they told you, oh, yeah, I just keep track of all my accounts and confluence pages. You will la from out of the room, and you know, a CRM is their way to codify and methodically track all their accounts and their opportunities and report on things and like make sure their sales organization is following sales practices and all these things. So why is engineering any different, Like that's what we do today, Like we have a bunch of confluence pages and we like just pray for the best. We have SRA teams and security teams who are trying to drive these best practices, but you don't have a way of methodically doing it. And so IDPs I think are men for organizations that are trying to invest in the injuring foundations to drive those outcomes and do so in a methodical, kind of data driven way. Those are our best customers. Like folks that see engineering and software as a competitive advantage and believe in investing in injuring foundations as a way to drive business outcomes should have a system that enables that set of practices. Broply speaking, so long would an answer, but if you if you were investing in injuring excellence and IDP is probably part of that journey in some way. Long winded answers are Okay, we got a whole podcast to fill here. No. I like that analogy though. This I hadn't heard the CRM analogy before though, and that that resonates so well with me because one of my first jobs in you know, tech it software engineering was around CRM, because like this was in what was it, I think it was late nineties, early two thousands, you know, and everyone like CRMs back then were like you know AI today, where everybody was just like pimping it out. But it's true because I think that that analogy is just so cool because from my perspective in my day to day work, you know, you're always like getting pulled off to take a look at this micro service or that micro service or what's this alert mean? And so the IDP is like a common source of knowledge where you can go see like not only hey, what is this thing, but where is it? Where's it running at? You know, and how is it deployed and whatever pieces are connected to it. Exactly, Like if you know, what's really interesting is that every single function in an organization has some sort of system of record, right like HR has HRS systems like Workday and sales have CRMs, and I guess marketing also use the CRMs, but they also have things like MARKETO and finances ERP and then Enguring built all these other CRMs, but we didn't really have one ourselves. And it's really interesting because the same things you hear in other functions, like you know, support ticket comes in. Like imagine if every time a support ticket came in, your support team was like who owns this account? Again? Like what does this account? Do? You know? What kind of customer are they? And you just kind of ping each other on Slack at a conflience s Pase you do that, it'd be insane, but like that's what happens today. In engineering is like, hey, I have a question about the payment's API. Who do I go to? Again? Like who do I talk to about that? Like like that is the current state of affairs for most organizations and so like the fact that every other function software drinking teams have solved that for everyone else, but we haven't sold it for ourselves is like such a bizarre chicken or the egg problem to me. And you know, I think the other like best example of this is the fact that most of these other functions use their system of record to drive kind of like purpose build process for it. And I'll give you an example of this, Like you know, sales teams they have you know, medpick or whatever kind of like sales methodology they want to use to drive like quality leads. Like a sales leader will come in and say, hey, I you know, I'm not gonna treat this as a real deal unless you know what the pain is in this account and you know who the decision maker is, and like you've done all this discovery until you do that, Like, I don't even treat this as a real deal, and all that stuff has codified it into this CRM, Like you cannot move a deal forward in stages and unless it has that information and like that forces the behavior you want. But in engineering, like we don't really have that, Like if you the the best example of this is like production readiness process, right, it's like, hey, you have to follow all these standards and like meet these requirements and you have to do things in a certain way so that when you go to production, like we're not gonna waste time being like where the fuck are the logs? Sorry for mind you, where the logs for this thing are? Like you know, like who's on call for this? Like is there an escalation policy? Like is there an uptime honitor? Why did this go off? Like that? That's kind of the current state in production readiness process is like this is a very manual thing, and you know with SRR teams, you have SR teams that like will interrogate you before the thing goes to production, like have you done all the things you should do? And they're like yes, I have, like trust me, and it's an honor system thing, and so why is that any different from a sales team kind of like codifying these things in a system. If sales can codify things, why can't the function that codifies things for a living codify those things into a system too. And so you know, like product readiness is a very common thing people do with IDPs because you have kind of your core catalog with services and ownership and all this metadata. Now that you have that, you can say like, these are the things that I care about from a product readiness process, and I'm going to codify this. I'm going to valuate all these things are true and I we'll just tell you if you're not getting those requirements. And so I don't know then now. The moment we came up with this analogy was like like suddenly, you know, everything clicked because every function has the same problems, Like we're just reinventing the wheel, and why do that when we've learned these lessons the hard way over and over again and like every single function And so I really really love that analogy. Yeah, that's cool. It just works so well. You mentioned that, like your SRE teams are your biggest advocates of this, what kind of like what are the big challenges for them to get that, to get like support across the org for that. Yeah, you know, I would say like our biggest advocates are usually platform engineers, sorry security and like developer experience, though I think developer experience has been generally subsumed by like DeVos platform groups at this point. SORR is a really interesting one because they don't necessarily see an IDP as just a platform or like the system record is a platform, you know, kind of extend this extending this analogy a little bit. It's like your customer success team. You know, they probably don't own the CRM, but they are like major stakeholders, and if they don't have information about your customers, their lives are a lot harder. And so SRA teams are kind of the same, where they just have a very specific pain point and it's usually around you know, being the first line of defense during incidents or running production by processes and whatnot. You know, like let's say an e commerce company. For example, we work with a really, really well known e commerce company and every year they run a production readiness process to get ready for Black Friday, because you know, majority of the revenue comes in on Black Friday, and so you can imagine that they probably have some of the best production readiness processes in the world because you you bet their systems are precurely ready come Black Friday, cyber Monday, and so your SORRY team comes in and they run this entire process around it. So things like load testing and contract testing and you know, monitoring and alerting and logging and all these things are like those things have to be ready to go come black Friday, and so how do they do that today? You know, it's generally a combination of spreadsheets and you know, tracking down service owners and like manual processes around this kind of thing. And you do that year over year over over year, and it's just like and you end up in a state where there's tons of drift. Right, it's your I SR team owns the outcome of reliability. So you know, from a CTO perspective or a business perspective, they're the ones that are kind of the single choke point for reliability. If things don't work the way they expect, the first question is like, hey, SR team, what happened? Right? And so it's like they have invested interest in making sure that reliability practices are codified and it's not just them. I think SAR is unique in the sense, like all these kind of core teams I mentioned, like Platform and Sorry insecurity are unique in the sense that they don't really have a direct impact on what other teams do. They're more like influencers in an organization. They can say these are the things that I need you to be doing. But unless there's a mandate from like a VP, begeering or CTO, they can't hold other teams accountable. Right. It's more like, here's a process that we're going to put in place, and like hopefully you get buy in from the leadership team to use those as gates. But like that's one of the biggest pain points is that there's like there's the problem of they're being held accountable to a major business outcome, but they don't have the quote unquote how we're to enforce that across their peer groups, and so they're kind of in this weird situation. And so I think that's why they love IDPs is because now they can codify this requirement in a systematic way. So they use the catalog and they codify their pressure readingness process, and they can generate reports for leadership. They can you know, assign action items to developers, and they have a way to like continuously monitor these things. And I think that's the other thing about IDPs is like I sorry. Teams obviously are pushing the idea of like observability and monitoring and all these things, And so if we really care about real time visibility into those things, why do we treat a process like pressure waightingness as a one and done thing, right, It's like, oh, you check it off and like we'll come back in six months. When anything can change in six months, I could, you know, blow away my page duty rotation And I would never know that until something went wrong and people are like, oh, why did you get paid? Well, ah, my bad, Like I accidentally turn off all the notification settings on this thing, and so why wouldn't you continuously monitor that? So I think that's one of the reasons why I Sory teams are kind of such strong stakeholders is because they want a methodical, automated way to codify their practices and drive behavior change across the organization using like a system rather than just like an honor process. And then of course having a catalog and ownership and all those things are really important because when there's an incident there, they don't own those services, and their first thing is like who do I go to? How do I like? How do I loopen the right people here and if you don't have a system for that, again, you're like at here who owns payments and you can wait, you know. And so like being able to go to a place that says a show's payments and I will wake them up because this is Brandon down somewhere and like validated. So my life is so much better. So that's why your teams love IDPs for that reason. Yeah, the at here message is like the the pleas and then the at channel is like, Okay, this isn't This isn't a funny question anymore. Exactly exactly, that's exactly right. There's always that big side when you get paiged and you look at the alert and you're like, wow, I've never even heard of this service before. Exactly, this should be fun. It's just like your heart sinks and it's like, oh my god, what is this thing? Like this does not sound like a thing that it should exist. Right. I will say I think I was definitely a culprit of this in my last job. I'm a sucker for great micro service names. But I will say I think over the last few years, most organizations we work with have gotten much better about just naming things what they do. Cortex included for the most part. We definitely have our culprits here and there. But I think it's a lot easier to understand when something is named payment service versus bank emoji or something like something stupid like that. Oh for sure. Yeah, yeah. I remember when I first started my career, like there was for several years there was this big trend to name all of your servers after like Simpson's characters or Lord of the Rings characters, and so you would get paged in the middle of the night because Homer has crashed and you're like, this is not helpful information. That that honestly didn't change with micro services. I think like my last job we named and again I thought this was awesome, Like we had a you know or automated like decisioning stack for like credit card decisions and stuff, and it was all named after like Espresso, because you know, you have Brewer, which like takes the stuff from Espresso and then like or like the beans and then extracts things out of it. So it's like a feature feature extraction tool for the machine leading models. I was like, Brewer is such a great name for that. You know and like you know, stuff like that, and like that was a whole theme around that. And but now looking back, I'm like imagining a new engineer joining the team and you're looking at like what are these like coffee services? Like what is this to do with anything? So, yeah, I make coffee exactly exactly? Is that a side business? Like Nope, definitely not. Cool. So a lot of this paints an organization or steers an organization to a new level of maturity. But what's the entry level of maturity to get started down this path? Like do you kind of have to have a pretty good grip on where your environment is to start getting benefits from implementing an IDP. I'm really glad you asked this question because this question probably comes up like six times a week. I mean, I think it's a natural question asked. It's like, hey, if we're telling folks that you know, you should be more data driven in the way you operate than the force of the question is well, my data sucks, Like where do I start? And it's kind of this chicken or the egg problem, right, It's like, well, do I go back and clean up all my data first, or do I start with an IDP, and then you know which direction do I go? And my answer is always, if you don't have a system of record, how do you even know if your data is clean? Like you can sit there scrubbing all day long and you will just never know when you've actually reached a reasonable point. And so like the way you think about it is when you first start everything, like to take a famous line, everything is an unknown unknown, right, It's like you just literally have no idea. Everything is just a black box. And then you put it into a system, like you know, like an IDP and the catalog and all these things, and then you write scorecards and like kind of data quality checks around those things. Now, all of a sudden, you may still want to know things, but we've turned the unknown unknowns into the no unknowns, like hey, I don't really know what the service does, or I don't know where it's deployed, or is this thing even a production service anymore? Like which team owns it and whatnot? And so like at least now you know that that thing exists and you know that you don't know things about it, and then you can start to fill in the gaps with like automation or like human in the loop processes or whatnot, and so like, without a system, how do you even know where, like if you're making any progress against this or where to go against this. Like, for example, one of the things that we always hear is like, oh, well, well, first we need to figure out ownership for all of our services and and then we'll ask people like that contacts about those services and whatnot. And what's what's really interesting is, you know, we've we've solved the ownership problem in a really interesting way where we can use like machine learning techniques to determine owners of services and so that that's not really a problem anymore because we can like tell you with like a ninety five percent accuracy which team who thinks owns owns a given service or repo. But even without that, like it's probably easier for most organizations to say, these like ten services over here generally make up like the payments system of things, and so like, being able to like at least classify repos and services into these buckets then allows you to say, well, not just do I not know anything about these services other than the fact they're in payments, I can start to make more data informed decisions around we're to start collecting that data, are cleaning up the data, like, hey, you know the the Payments Organization sixty percent of their stuff. We have no idea what it is, so you know what, let's like ignore everything else for now. And it's really focused on like getting that data in order because that stuff is really really critical, and then we'll get to the other stuff. So how do you do that with that IDP? And so that's why like with the chicken or the thing, and then you have to start with the IDP as a way to like codify this stuff and use it as a forcing function to turn the unknown unknowns into the NOE unknowns and hopefully eventually the no nones and then maybe a long tail of no unknowns. And so that's the kind of way I think about that problem. Right. So it's like the difference between knowing I'm screwed and knowing how screwed I am. Exactly exactly, that's exactly right. Cool. So then you can just kind of like almost just create a process where first step is look for this thing, something something draws your attention, you look for it in the IDP, and if it's not, their first step is to add it to it exactly. I mean, hopefully the IDP you're using is able to like suck in everything, and so it's like that's kind of what we do is point us to your tools and we will just suck in as much as we can, so at least we know that those things exist in your world, and then you can start like filling in the gaps. So that's kind of where we would start, is like this this thing exists, and hoole like we started like plugging in the holes and the data, you know, hopefully with automation or like a human in the loop. And so you can always go to the IDP and start there and then kind of jump out into the other tools if you need to. Right, And so you pointed at like your your cloud provider and data ge hub, your data. Hug, your AWS and all that kind of stuff and say like here's everything we found. Let's second as much as we can. So now you have like a starting point again kind of turning the uh, the unknown nons into the non unknowns until like being able to then quin a quarry against this and say, you know what, I'm gonna like ignore all the things that haven't had to commit in like four years, like those repos that just don't want and so you can like run a report on that in the IDP and like put those aside and then folks on all the other things. And like, because we all know there's like a thousand repos out of if you have a thousand repos, eight hundred of them are probably random script repos and tour into them are real. So like how do you start to categorize those things and like meaningful ways and you know, being using IDPs like being able to put things aside and like start to focus on things. This is like an interesting way of something that problem. If gethub ever decides to start charging per repo, we're all screwed. Oh my god, that would yeah, that would be a bad day. Yeah. Most organizations definitely have more repos than people, for better or worse. Oh for sure. Yeah, yeah, for sure. So from a I think it's really easy to sell the story of an IDP to your DevOps and SR and infrastructure teams. What about to like the developers who are building the micro services. What's the what's the incentive for them? Yeah, that's it's an important question. I think. You know, our thinking around this has kind of changed quite a bit when idp's first came around, especially like you know, the open source framework from Spotify backstage and stuff like. They they really focus the messaging around developer experience, Like the main thing was just developer experience. And I really think that was a bad framing for ADYPS because it focused the entire thing on just developers versus how does it fit into injuring excellence and then run you know, then focus that on developers. And you know what I mean by that is like developer experience we kind of see as a subset of injuring excellence, right, So it's like injuring excellence is the alignment of your like general technical strategy to drive business outcomes. And it's like the it's the entire life cycle, you know, starting from architecture gains in response to production, to security posture and all these things like that, all of that stuff falls under injuring excellence. The developer experience is kind of a subset of that, which is, you know, we want to optimize the developer's workflow, sending tools, documentation CI, reducing friction, cognitive load, like improving sentiment, all those things kind of like fall under the developer experience bucket, right, And I think the to to kind of bring in another analogy here. Developer experience is kind of like the ergonomic office chair, right. It's like you need it for comfort and productivity, and you need it to to not fall apart and have a bad back in like five years. You could still probably you know, write a ton of great code if you were hunched over on your sitting in your bed and coding. Like it's you can still do good work, but you will probably kind of wither away after a couple of years and like not beasi reproductive and you're gonna hate your life and all those things. And so it's like injuring excellence is like the general operational strategy to like, now that I have a chair and people are comfortable, how can I you know, how can they write code that actually matters for the business and do it in the right way? And so like all that to say, I think when we think about where developers fit in, I think it starts with like, what is the business outcome we care about? So for example, like I mentioned for the e commerce company, it's like we want reliability, and for reliability, it's like okay, well, now the s RA team owns a reliability initiative or on injuring excellence, and they want to make sure that any new service that is being deployed to production is following all these practices, including new ones. And so they go and work at the platform team and say like, hey, we want to build a golden path, you know, and we want to incorporate our SR practices into the golden path that the platform team is building. And so now you have your two central teams working together, and they take that and they deliver it to the developer team and they say like, hey, like this is our production readiness process. You have to meet all these requirements to go to production. By the way, we also have this real easy starter where if you click a button, we will create a repo for you and bootstrap with all the right things and like registrate with data dog and set up your monitors. And so you can use a starter and get all these things for free, or you can kind of go down your own path, but you will still be set held to the same requirements. And so now you've kind of tie the two things together. It's like the develop the seamless developer experience around spinning up a new service or self serving something is tied to this kind of like outcome that we care about, and so like that's the way we think about where IDPs drive value for developers. So it's like you can you still have really great developer experiences around. Hey, I need to figure out who to talk to when I have a question about a thing. Let me go and ask the catalog. Or I'm trying to spin up a new service, like let me just go click this button and like get a new service in two minutes versus going and copying a thousand boilerplate lines and trying to set up things myself. But it's like all baked into this concept of injuring excellence, you know, like the other examples of this like that we see it with IDPs is things like temporary credentials for database, Like, hey, I need temporary access for some vault and I need just in time credentials. Okay, cool, Like that is a security outcome that we care about, and I could probably do this as like a jear ticket that I can go and file and like assign it to the security team and they can review it and they can send me like a secure link with the credential or something silly like that, or they can bake that into the IDP and say, hey, click this button. It will notify me when you want this thing, and I will approve it and you will just get your credentials there. So it's still like in service of security, but the developer experience is awesome and so why when a developers use it? So it's really around like I think a lot of IDP initiatives fail and it's general development like not even IDP like developer experience initiatives or platform managing initiatives fail because if you have the mindset of if we build it, they will come, it never works out. Like you have to be solivent a very specific pain and like think about it like a product manager and run like drive to where some outcome. And then if you do it the right way, then developers will naturally like your adopt the capabilities because it is something that they are facing pain with today. It's like that's where I think developers get a lot of value out of the IDP as a whole. Yeah, And I think there's like so much overlap there for you specifically in that build it and they will come model because you were the one of the co founders of Cortex, so you know firsthand, like you've got your employee salaries on the line to figure out and you know, and decide like, oh, just because I built it doesn't mean they're going to come. So you have to you have to do that marketing, you know, and find out who's using your product, and who looked at your product and decided it wasn't for them and why. And I think those same lessons have to be applied internal to the organization as well for a product of this scale to be successful. That's exactly right. I mean, coming from a technical background, our first iteration of this was literally like, here's a catalog. It solved that you know, sinking feeling when I got paid at two am for service Dinefic Gamston's character and we put it out there and we're like, why does nobody want this? And it was like it was I don't know. It was such a moment for us because we were just so focused on solving for this one and specific pain point the way to take a step back and think about, well, yes, this pain is hard, but how do we show people the value of this? How do we you know, make it so obvious that this is the right way of doing things that people will want to adopt it and like maybe overcome friction around it. Like platform engineering or DevOps is no different, right, I mean we've gone through this time and time again. It's like, oh, you know, we've like rebuilt our CI process and our cipipeline and the's all these other tools, and you're like, why is nobody using it? Was like was there any real pain around it? Like yeah, maybe like the old system sought, but like like is it is? Is the new system so much better in so many ways that like I will take six hours out of my week to migrate my you know, my repos over to this new CI process Like maybe not, And so like either how do you make it super simple for me to migrate like a click of a button maybe an IDP or it's so much better? Or like I you know, went out and researched with my my developer teams and asked them what the what the pain is or saw metrics like you know, it's not just about I think, you know, maybe a hot take, but I think a lot of organizations are overdoing it on the surveys, Like surveys are useful, but you know, if you ask what people what their problem is and what the data says, there's generally two very different things. And so like a combination of data and outcomes and surveys and all those things are important. But like you know, going and talking to your developers like hey, what do you what do you do all day? Like we know, what what is your experience on this thing? You know, you know, you have all these requirements from security team, like how are you fulfilling those? What does that process look like? You know, what is the pain point for you? And all this stuff? And like then you start to realize like, oh, man, like I'm starting to see a theme in this particular part of the process, Like that's where I should really focus. And it's It's interesting because a lot of platform and DevOps teams have been given this charter like go figure out developer experience and platform stuff, and that is like that is a product question at the end of the day, like you have to think like a product manager, but a lot of platform teams or DevOps teams are not assigned a product manager, and so you're expecting, you know, these new platform teams to like piece together. They're like platform skills and like devop skills and all these things and like somehow like magically learned product management and all this stuff and like figure out the best platform. And it's it's like a tall order to ask. I gave a talk about this at Reineman because it's like such an important thing. Like I think platform engineers really need to think about the same way that a product manager would do. Right, It's like it's not just all, let me just build a really cool product. It's like what is the point of this product? Like what does the business care about? What is the outcome that they're trying to drive towards. What is the foundation that we need to build, and how does this platform help us achieve that outcome? Because you know, I think we see this a lot like injuring leaders or like especially non technical leaders, but look at teams like platform teams, thedop ops and like what is this team doing? Like what do they do all day? Like it's easy to point out our product team and say, like, yep, they ship eighteen features and I know exactly I saw that in the UI, and my sales team is able to sell it, but the platform team is much harder to like quantify the impact of that and so being able to tie it to some like bigger business outcome is so so important to like get that time and energy and resources to like keep investing in the platform. The right way for sure. Yeah, and especially like if you try to pull the platform team, like so many of us are just like grumpy and skeptical. So like if you start asking as quickquestions were like, what what do you want? H's this going? Just tell me what's broken and I'll go fix it. Otherwise go away? Yeah exactly exactly one percent. Cool. Yeah, So, like one of the things that successful startups do really well is fail fast, you know. And there's like there's that quote from Zuckerberg a long time ago, move fast and break things, which I tend to disagree with because you know, it's like are we moving fast? Yes? Are we breaking things? Yes? Are those two things related? I have no idea, you know, because like I could, I could break something and it maybe six months before we notice that it's broken. And so I like the term fail fast a lot better because it implies a feedback loop that you're actively trying to make what you're currently working on fail, not something that's been working for six months. But anyway, with fail fast, I think that's one of the key, one of the best ways to figure out what your customers really want quickly. And in the case of an IDP, like the customers are the rest of the engineering org. So what kind of initiatives can you start with for an IDP that lend you lend you to a fill fast mode of operation. Yeah, this is something we've learned the hard way over many years of IDP rollouts. I think the most important thing and this is this is true for like product, you know, kind of like failing fast. The most important thing about failing fast is to deliver incremental changes, right, Like you don't ship a ginormous thing and spend six months building this out and then fail Like, that's not failing fast. It's like try small thing generally, like move in the direction of the problem, trying to solve, see if it works, and then like it doesn't work, try a different approach. And I think for some reason, I guests thrown out the window for a lot of IDP initiatives where like, oh my god, IDP can do a thousand things, let me go do everything. I'm gonna build the catalog I'm gonna build the self service, I'm gonna do all these things, and like you're rolling the ocean and then everything fails, you're like, it must be the IDP, and it's like, it's not the IDP. It's like, I think that all the things you tried probably didn't work. And so I think the thing that we generally say is when you're rolling in an IDP, start by taking something that you're already doing and making it better. Like, don't try to introduce net new tooling or process or stuff, because you're trying to change behavior at that point and that is really hard. But instead, if you can take something that people are already doing but it's made better by an IDP, that will help you iterate a lot faster, Like I know we have to do this anyway, I know it sucks. I will iterate against this one thing that I know we are doing and make that better until people tell me it's better, which is a much easy your proposition than let me go and invent a whole new thing that we've never done before and then figure out how to make that work, which is like the difference between taking an existing product that is like selling decently well in the market and like iterating on it versus let me go and build a whole new product line that I have no idea people want this thing, and then iterate on it and maybe the entire company falls apart, you know, and so like that, like that is how we think about IDPs, and so pressure readiness is a great example of that, because it's like a thing that most organizations do and it's usually pretty painful. And so can you invest in your automation and tooling your IDP to solve that very one thing and solve that for every persona like, solve it for the SRA team, solve it for developers, solve it for leaders, and everyone's like, yep, I get the point of the IDP, and this is so much better than what we were doing before. What else can we do now with the IDP or the same thing If you have a very manual like self service process, If you don't have a self service Golden path process at all any way, shape or form, it's probably difficult to start there. But if you have like a semblance of that process, then investing in that can be much better. Only if you can tie to some sort of business outcome, so you can say, like, you know, leadership team is really focused on deploy frequency or you know, more innovation. It's like, okay, well that translates into the self service thing that developers already doing. So I'm going to showcase that one thing and iterate on that really rapidly until I show something valuable. So like being able to like take a kind of like a single thread through the entire organization across personas is like the way to fail fast because you're working towards something specific and iterating very quickly against that. Right on. Cool, And I think it also is just going to give you a sense of a sense of control over the implementation as well. You know, because you just focus on one thing, you're not constantly context switching between you know, ten different implementations or ten different major initiatives at the same time. Exactly, exactly. Cool. So what's got you excited about the current state of technology these days? Man a lot? I think you know, it's I'm glad we are generally over the conversations around what is the kind of cloud technology we all want to use? Like everyone agreeing on Kubernetes is like the standard for the most part, is like much easier because these now we can make it better. So I think that's obviously really exciting. I think I'm sure ninety five percent of people that come on this podcast probably say AI, which I will also say, and you know, for what it's worth, that was play an AI skeptic for a while. And I think, you know, some of the new models, like the reasoning models and stuff, are really really fascinating and I think we're going to see a lot of really implications around that. But I don't think traditional you know, machine learning techniques are going away either. But I think it's really exciting how much more accessible though that has become for a lot of people, ourselves included. The fact that we're using a common of AI and traditional machine learning techniques for kind of data discovery is really cool. And yeah, I think the I guess the last thing I'll on technology perspective, at least from my lens, No, I think about like organizations more than technology a lot. And I think what's really cool is that organizations. I feel like in the last five to ten years, the way we operate, as in your organizations, have matured quite a lot. I think, I know, I think things will keep changing for for some time, but it feels like for the most part, we've generally stabilized into kind of these different pillars of injuring excellence. And you know, I think I think platform engineering is here to stay. You know, I think, you know, we've we went through the kind of iterations of cloud, infra and DevOps and all these other things, and I think platform engineering is like the right iteration of that process, and I think we're gonna see I mean, I think that's why we've seen it kind of subsume developer experience and developer activity and all these kind of other ancillary functions. I think SR here is here to stay. I think security is obviously here to stay. And so I think we've seen like injuring organizations generally stabilize on like these are the things that we need to invest in order to enable the outcomes that we care about. And I think it's exciting because now we can start to build like purpose built capabilities for those functions rather than like trying to figure out like is this DevOps, is this cloud as this platform is this infra? Like where does this all fit in? And like I think, you know, knowing how the organizations generally interact with each other is like a really powerful thing from up tooling perspective, and you know, tying it back to the CRM analogy from earlier, it's like, I think that's why you have so many interesting tools in the sales space is like for the most part, it's like generally stable. You know, you have your your sales reps. You have your sales engineers, you have your account teams and your customer success people marketing people, and you have like your OPS teams, and like generally those teams work together and like that has been fairly stable for like the last two decades, and so you know, you now have a crop of tools that I've like made each of those people's lives so much better. So I'm excited for that engineering and like seeing those organizations stabilized means we're going to see a lot more like a really interesting tools, especially with AI, so we're gonna see a lot of really interesting, like purpose build tools. I'm excited for for that kind of next iteration of innovation around that From an organizational perspective. Yeah, for sure. It's it's like we've actually gotten a good answer about what we do. For the business exactly. You know, like because for such a long time, you know, we were it was just everything about our industry was just a cost center, you know, and if if companies could just due away with it completely, they would. And we saw that a lot in the the late nineties and early two thousands without so we're seeing to you know, India and other countries because it was just like, Okay, it's a cost center, so we want that cost to be as small as possible. And now I feel like we've got a and part of it was, you know, a learning curve on us in engineering, or we had to learn what we were doing for the business and how we fit into that part of the business and then start articulating that. And so I think we got better at that. And uh, I think another interesting analogy that applies to that is like looking at the automotive industry. You know, whenever they first created automobiles, you know, it was just guys in a shop somewhere are building stuff, putting parts together by hand, and then they came up with the assembly line, you know, and then once you had the assembly line, you could start creating industries that fed products into the assembly line, and you had then you had just in time manufacturing and that kind of stuff. So I think it's a very similar pattern that we've seen over the last few decades in engineering. So same pattern, just on a much more accelerated timeline exactly. And I think that analogia works really well because we really saw big improvements in the methodologies and the technology around manufacturing when organizations started to see manifact like the way they manufacturing and manufacturing process as a competitive advantage, right, was not just like it was just a thing that we have to do to like ship, like to build a build damn things. It's like, now, if we do it right and we invest in it, it is actually a competitive advantage. And we see you know, companies like you know, Toyota or even Tesla, you know, investing in like automation really seeing the manufacturing line as a competitive advantage. And I think software is the exact same way. And you know, when we talk about it internally, that's what that's how we talk about it is like our ideal customer is a software organization is a company that views software as a competitive advantage. And more and more organizations see it that way because you know, like software thing in the world, and uh, you know, we've all heard those those those lines. But if you see software engineering as a competitive advantage, then of course you're going to do everything in your power to make that function as productive and uh, you know, outcome driven as possible, and that lends itself really well to IDPs and platform engineering and all these other things, and so like, of course you would invest in the right teams and tools and process to make those teams move as quickly and as efficiently as possible. So yeah, it's been it's been a very interesting transition for that purpose. And like even you see this with like with offshore teams. A lot of our customers have offshore teams still in India and things like that, but the way they see those teams has changed drastically. Like you know, people are constantly flying out to go and visit those teams, and they're building beautiful campuses in India, and like they see those teams as part of the strategy versus just like oh, it's just under cost center. So it's like, hey, how do we enable those teams that are you know, thirteen hours away from a time zone perspective? How do we help them operate really well and independently and put it in the right processes so that they can move quickly. And again like, those are those maybe things that you would have done if you only saw them as a cost center and like a way to cut costs, But like the framing of it changes a lot when you think about software as a competitive advantage. Like the way you invest in the tooling and the platform to let those teams move autonomously and quickly is very very different, and we're seeing that in a lot of our customers and it's been really really cool to see. Yeah, I think one of the really strong indicators of that shift in philosophy has been some of the companies adopting like a global pay strategy where they're no longer paying a competitive salary based on where that individual is, or saying this is a competitive salary no matter where you are in the world. If you're working at that role in our company, this is a salary you're going to receive regardless of where you live. And I think that's a true That's that's the company, you know, to use the old phrase putting their money where their mouth is. That's them saying, yes, we value this position and we're willing to pay for it. Because of the benefits that we get as an organization. That's exactly right. That's exactly right. So you're in San Diego, right, I am right on, such a beautiful town. I love it. I went I went to undergrad here. I grew up in the bar area, Okay, and went to undergrad at UCSD and moved back to the Bay worked there for a few years, and then, like everyone else during COVID, I was like, why would I not go back to a sunny, beachy town to move straight back here? So is QRTEX still remote? We are. We have people all over the world at this point, and we just opened up an office and New York. We have quite a few people out there. But there's no like RTO or anything like that. It's just just nice to have a place for people to connect and you know, hold customer events and all that kind of stuff. But we have people throughout the US, people in Europe, people in Apac and so on. So definitely a global organization right on. Cool. What do you do, like like planned events or get together is to bring folks together at at regular intervals. We do. We're very very intentional about that. So we do two all company events or fly everyone out. So it's actually probably more expensive than just having a couple offices, to be honest, but yeah, you know, the the talent arbitrage of hiring remote and like the productivity gains are like so high that I think it's still valuable. And so we we will fly everybody out to a single place. So in February we do like our company company kickoff for the year and holiday park, so we actually for that one will fly out everyone's partners or spouses and plus ones for the holiday party, which is really nice to get to know everyone and like really you know, meet everyone in person. And then we have like you know, three days of working sessions and all hands and team bonding activities and all that stuff. So that one's usually in New York, and then we do a second one in the fall. That one's usually in San Diego because the weather is obviously so nice here during that time, So we fly everyone out for that one, and then we do a bunch of like smaller events throughout the year. So like for big project kickoffs, you know, injuring, teams will meet up in person, or the sales team does their qbrs in person. We meet at conferences, there's a lot of opportunities to meet in person then obviously like ad hoc things as well, but we are very very intentional about creating those in person opportunities, especially because we're remote first. Yeah, for sure, Like I think really async communication works best if you do have those in real life get togethers, because there's there's a level of bonding that happens in real life that just doesn't happen whenever you're just talking to someone you know via DMS or even through video chats. You know, you just there's something something about humans that it just doesn't work unless you're standing in close proximity to them. Exactly exactly, Like remote work is made ten times better after those in person events like getting to know people and you know, meet in person makes those asynchronous and synchronous online connections just that much better because you've built like a human bond with that person, which is extremely important. Yeah. Yeah, the person is no longer just the Homer Simpson emoji and slash. It's an actual real. Human there, exactly exactly. Cool. So what are the next big plans for IDPs just in general and for you at Cortex. Yeah, I mean, I think the big thing for us is to kind of keep doubling down on this injuring excellence idea. So, like, how can Cortex be the platform to help organizations achieve a higher level level of injuring excellence and how do we get people kind of thinking about this framing even more as well, Like most organizations are already doing this, and so like, how do we tie all these things together and help organizations see that outcome? And how how do we continue building the product in a way that drives towards those outcomes in many ways and you know, investing in things like you know, injuring metrics and reporting, investing in developer experience tooling, investing in automation. Yeah, really just helping kind of be that command center for injuring excellence, Like how do we help the entire organization, all the personas be better at engineering? Like that is a you know, an important distinction from I think what a lot of IDPs make, which you're really focused on just developer experience. And so I think, you know, doubling down on that from a product strategy perspective is gonna be really interesting. I'm excited to see where that goes. Do you feel like you've already picked the low hanging fruit in the industry, or do you think there's still more easy wins to be had there? I think there's a lot more, well not easy wins. I think there are obvious wins, but technology technologically complex wins which we're currently working on that unfortunately can't talk too much about but hopefully we'll be able to share in a few months. But I'm really really excited about the possibilities, Like they're the market. Yes, we've been around for you know, five and a half years now, but in the grand scheme of things, you know, going back to CRMs, CRMs have existed for like forty years, but sales teams, I've been doing general bookkeeping for like centuries probably like you know, there's like the classic you know that QNA formed uh tablet from the Sumerian civilization around like the bushels are great, and like the documentation around that, you know, on the tablet, and so like, I think sales process existed in some shape or form for like centuries. As we're kind of like speed running that process with with IDPs a little bit. But I think and so with that framing the fact that idp's have been around for like six years, and you know, I think I think we're like the longest standing at AP at this point. But like that's a drop in the bucket, you know. It's like there's like so many more things we can do with with IDPs, and I'm really really excited about the possibilities there. For sure, you're you're six years into the three thousand year journey. Exactly, exactly, exactly, We're killing it, man, exactly. Oh yeah, right on. We'll definitely have to come back on a show whenever you do drop that new feature that you can't talk about now, because I'm I'm interested in that now. Absolutely, we'll definitely reach out. Right on cool Cool. So what would be what would be a great first step for someone who's wanting to check out the IDP experience. Just go to cordexa io. We have a demo on the homepage and click around, see what it looks like and get an idea of it. And we are actually hosting a variety of injuring summits injuring excellent summits throughout the world. So we have one in New York, one in Boston, one in London, and one in SF and so those are not like super IDP focused, but really focus on injuring excellence. And so if you're interested in kind of how it all fits in, come up, come through to one of those those summits, meet a lot of other drink leaders and practitioners. I'm really excited for those. And of course IDP Con we held the first one last year, massive success. I think we had like three hundred people or something close to that turnout in New York. So we're holding it even bigger and better this year. So all things IDPs, not just Cortex, but all things IDPs IDP com later this year are probably great. Great example, right on, is that going to be in New York again? Yeah? All right, cool? Cool. We are looking for speakers as well, So. Okay, yeah, is there a CFP form on your website? There is, I believe it's on IDP CON's website, which is IDP con dot com. And there is an apply to speak one in so looking for any and all cfps for. That, right on? Cool, So that'd be cool. Check out the conference apply to speak. I always courage people to apply for speaking positions. Great opportunities. Yeah, it is. It's scary as hell. The first time, but then once you do it, you're like, oh, all right, I get. It now exactly, and it's it's full time on other people who could get what you're doing, and like, I want to talk more about it as well, Like it's a being able to have interesting conversations with practitioners after your talk is like it's always cool. Yeah, for sure. One of the things for me because I'm not like a super social person, like I yeah, I'm just not a social person. But when I started giving conference talks, I did it mostly just as a challenge to myself. But then I found that by being a speaker there, I never had to struggle with what to say to strangers because everyone always had like a question or a comment or some way to start the conversation about the talk that I gave. It's like, oh, okay, well let's it's not near as intimidating or as stressful as I was expecting it to be. I encourage people to Yeah, I encourage people to do it just for that reason alone, and it's just great for their career as well. You know, you put it on your resume next time you're applying for a job. Oh yeah, it was a speaker here. It's just like instant credibility, only good things. Yeah, for sure. Cool. Well, what do you say we move on to some pics. Let's do it all right? Cool? So this week I'm picking a book that I've just started reading, Plato five Dialogues. And you know, I'll be honest here, I grew up in Texas in the seventies and eighties, So I don't think anyone's going to be shocked whenever I say I had never read Plato before, Like I've read the back of a Coup's Light Can thousands of times, but this is my first time. I'm reading Plato, but I haven't read them. It's cool because the book, oddly enough, written by play Out, It's got nothing to do with him. It's mostly about Socrates. And the reason I'm picking it is because I learned that Socrates seems to just be a big fucking troll. He didn't really do any well, just that he would just engage in arguments with people just for the sake of screwing with them. You know, the one that I read yesterday. He was talking with this guy about the difference between piety and impiety and gets his definition from it. And then goes through some different examples and then slowly walks the guy around through to the point where the guy changes his definitions of what those terms mean. He's like, oh, so now you don't know what they mean, because now you're saying it's the exact opposite of what you just told me. And it's like, wait a minute, you just this whole time. Yeah, he's Socrates. The original, just to play Devil's adificate guy. Uh, for sure, for sure, if he were alive today, he would definitely be canceled. Oh man, So what about you? What you got for a pick this week? Oh? I was trying to think about it the whole conversation, and I actually came up with one. You know, the thing that I've been really kind of focused on recently is sleep quality. Oh yeah, it's I know, it's been in the zeitgeist for you know a couple of years, with like all the new like high fangled sleeping equipment and all these stuff. But you know, I've started wearing my Apple Watch to sleep and like tracking all my data and all this stuff and like using this just have to like track sleep data and things like that, and it's been really really interesting to see the effects of things like you know, my my dinner time and working out and all these things on sleep. But to the point of my reading. What's really interesting in what I found is more than anything else, reading before bed with you know, like dimming the lights and you know, blocking blue light and all that kind of stuff. But then reading for about fifteen minutes has had the highest significant impact on my sleep quality than anything else. And it can be I mostly read nonfiction, so it's not even like like I'm reading just like slop to turn my brain off, Like it's like interesting stuff that I'm to read. But I got some trashy romance novel. Yeah exactly. I mean I'm sure that would work too. But yeah, just like reading for fifteen minutes before bed has had the most, like, uh, has the highest impact on my sleep quality I've seen in the data compared to anything else, and it's it's it is really really fascinating, and like I was a gracious reader growing up, and it's something I've been trying to get back into just like given time, it's been a nice thing to just be able to read and like you know, just get through books and stuff every day. But the impact on sleep has been incredible, Like I don't know, it's even more than like just meditating or like breathing or whatever. It's like reading has had an incredible impact. So you should think about reading that book right before you sleep. I'm gonna test your theory because, like I my wife, you know, she's always like using her Apple Watch, you know, and she breaks down her sleep and you know, does similar to what you're describing here. So I'm gonna challenge her to read for fifteen minutes and see how that affects. Yeah, for sleep quality, I've. Seen like the highest impact on both my heart great dips, so like how how much lower does my heartbreak go and how stable is it throughout the night, as well as rem sleep cycles, Like the amount of remsleep that I get is noticeably higher. I think the last time I checked was around fourteen percent higher or something like that when I do read a night, and that just like ten minutes of reading isn't enough. So yeah, she should be able to see kind of a noticeable impact in the data for it. And so like the top two things have been like eating dinner earlier, so you get like fewer like blood sugar spike throughout the night and then reading for ten to fifteen minutes before bed have been like the two highest impact things that I have done. Because I know you can do like a lot of things with like you know, cooling mattresses and all these other things, but it's like those are like much more you know, investment oriented, but like these are like small things that everyone can do, and so I think, like that's been what's really interesting about it is like very small, what are the most tactical lifestyle changes you can make to see noticeable improvement in the data, And like these are the things that I think that I found. So it's really really really interesting. So probably to experiment more with with this kind of thing going forward. Yeah, you can drop fifteen grand on a cooling mattress or spend fifteen minutes reading your choice, Yes. Exactly, exactly. Maybe I'll do both. I don't know, but right now, right this is good enough. Yeah, I've seen the cooling mattresses and I was like, oh, that looks so cool, but I know, I know, I just can't. It's just the technology, the gadget geek in me that like, right, yeah, those things I don't need that. I just read a book and it's good enough. Yeah, especially for me, because I I feel for you, guys like you, and people like my wife, because on a really, really bad night, it'll take me like forty five, maybe fifty seconds to hit deep sleep from the time I laid down. Oh man, I am so so jealous. I think it comes Oh my camera just died, but I'm still here. I think it comes back to early after I left high school, I joined the military, and on my first I was in the Navy, and my first trip out to see my bunk was right underneath the flight deck on a carrier, and they were doing flight operations the whole time, which is a I can't remember how much it weighs, but there's like this huge sled underneath the flight deck that slings the jets off the end and then it you know, they have to bring it to a stop before it hits the end of the aircraft carrier for obvious reasons, and so this thing's like going back and forth over your head the entire time you down there, and then you know they're like, hey, you know, this is your time to sleep. You can sleep or not sleep. It's entirely up to you. So I think that might have set some habits for me that are still working for the outfit. Now. Yeah, you can probably sleep through anything, now, I bet. Huh for sure. Yeah, it's weird through anything unless it's a noise it's not supposed to be there. Like I can sleep through thunderstorms and lightning and wind and trucks driving by, But the minute that there's a single noise that's not supposed to be there, I'm instantly wide awake. Interesting, Yeah, probably your brain is probably kind of wired that way to, like I guess, filter out things that are obvious to I guess is like general background noise. So I guess this is generally a good thing. Yeah, I'm definitely much much light sleeper than that, for sure. Well, I think about idp's all along. So I've actually read a lot about how much how much our brain does filter out just to keep from overwhelming our conscious mind. Like someone I can't remember what the numbers are, but someone had like an actual data rate and it was like something like, yeah, like two megabits per second is what our consciousness can handle our subconsciousness filtering out like forty gig per second or something huge like that. And I was like, well, those are cool numbers. Not really sure how you came up with those numbers, but it's it's cool, and it had had something to do with I was doing research on psychedelics and then that was like one of the things is like psychedelics, you know, like turn that filter off for a brief period of time because over time your brain learns, oh, this, this person's not interested in this. I'm gonna filter it all out. But then psychedelics like give you access to the full menu and allow you to say no, no, don't filter this out anymore. Interesting. It's an interesting framing. Yeah, I haven't really thought about that. It's been interesting. But anyway, so if people want to get in touch with you talk more about this kind of stuff, Ganesh, what's the best way. Adamil LinkedIn or shoot me an email? Ganesha cortex on Io. All right, awesome, thank you so much for being on a show. This has been a pleasure to chat with you. Thanks for having Yeah. For sure, and definitely let me know when you're ready to talk about the new hidden top secret initiatives on core text let me know. I want to have you back on I will drop you a note. Would love to all Right, cool and for everyone listening, Thank you guys for listening. Be sure and let me know what you guys want to see on the show, how you liked the episode or anything like that, and I'll see everyone next week