Speaker 1: 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?
Speaker 2: Great? Load to hear?
Speaker 1: 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?
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: Oh my god, yeah, one hundred percent. I do reasgually
remember that show.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Long winded answers are Okay, we got a whole podcast
to fill here.
Speaker 2: No.
Speaker 1: 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.
Speaker 2: 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?
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
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?
Speaker 1: Like that?
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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?
Speaker 1: Right?
Speaker 2: 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.
Speaker 1: Right.
Speaker 2: 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?
Speaker 1: How do I like?
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: Exactly exactly, that's exactly right.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Right.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Right. So it's like the difference between knowing I'm screwed
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
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.
Speaker 2: 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.
Speaker 1: Right, And so you pointed at like your your cloud
provider and data ge hub, your data.
Speaker 2: 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.
Speaker 1: If gethub ever decides to start charging per repo, we're
all screwed.
Speaker 2: 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.
Speaker 1: 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?
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: 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?
Speaker 2: Yeah exactly exactly one percent.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: Exactly, exactly.
Speaker 1: Cool. So what's got you excited about the current state
of technology these days?
Speaker 2: 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.
Speaker 1: Yeah, for sure. It's it's like we've actually gotten a
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,
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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: That's exactly right. That's exactly right.
Speaker 1: So you're in San Diego, right, I am right on,
such a beautiful town.
Speaker 2: 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?
Speaker 1: So is QRTEX still remote? We are.
Speaker 2: 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.
Speaker 1: Cool. What do you do, like like planned events or
get together is to bring folks together at at regular intervals.
We do.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Yeah. Yeah, the person is no longer just the Homer
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
just in general and for you at Cortex.
Speaker 2: 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.
Speaker 1: 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?
Speaker 2: 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.
Speaker 1: For sure, you're you're six years into the three thousand
year journey.
Speaker 2: Exactly, exactly, exactly, We're killing it, man, exactly. Oh yeah,
right on.
Speaker 1: 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.
Speaker 2: Absolutely, we'll definitely reach out.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Great example, right on, is that going to be in
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
is IDP con dot com. And there is an apply
to speak one in so looking for any and all
cfps for.
Speaker 1: 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.
Speaker 2: Great opportunities.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: Let's do it all right?
Speaker 1: 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.
Speaker 2: The original, just to play Devil's adificate guy.
Speaker 1: 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?
Speaker 2: 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.
Speaker 1: But I got some trashy romance novel.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Yeah, you can drop fifteen grand on a cooling mattress
or spend fifteen minutes reading your choice, Yes.
Speaker 2: Exactly, exactly. Maybe I'll do both. I don't know, but
right now, right this is good enough.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: Oh man, I am so so jealous.
Speaker 1: 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.
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
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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: Interesting. It's an interesting framing. Yeah, I haven't really thought
about that.
Speaker 1: 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.
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
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
to talk about the new hidden top secret initiatives on
core text let me know.
Speaker 2: I want to have you back on I will drop
you a note.
Speaker 1: 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