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