All right, what's going on? Y'all. Welcome to another episode of Adventures
in dev Ops. I'm your host Will Button, joining me my co host,
Warren perad what's going on? Warren? Thanks? Well, back again.
I you know, actually this week, I'm super interested in the topic
that we have lined up because in the last few few weeks we've been dancing
around different aspects of observability, and this is another flavor, and I just
I have so many difficult questions I'm hoping our guests can answer right on.
Speaking of our guest, Yeah, Roslin Whitley, director of product marketing for
can Tick the network observability tool for even when the network is not yours,
which is really cool. I think that's super cool, just because network observability
has changed since the days of whenever I was racking firewalls and routers and configuring
sn and P traps. Yeah, but welcome Roslyn. Happy to have you
on the show. Oh my gosh, you said configuring sn MP traps.
You didn't know those are the magic words for me for me to talk about.
You've fallen into a trap sor that's hi. Thanks so much for having
me on the show. Oh, I'm happy to have you here, and
I'm looking forward to this because network observability kind of has become a black box,
and we were talking about this before we went live here that you know,
it's just something that's kind of abstracted away with your cloud provider, which
you have a background in past services, so you're directly experienced with that.
And you even mentioned that you know, some DevOps people these days actively avoid
networking for just because of the complexity of it. So before we jump into
that, give us a little bit about your background, about what you do
and how you got there. Yeah, sure, thanks, I am,
Yes, you already said my title. I am a director of product Marketing
at Kentick, the network of our ability company, And it's been kind of
an interesting, interesting journey to get to this place. I think being a
being a marketer for a highly technical product requires a specific skill set, so
lots of us do have interesting journeys getting to that point. And I what
I was like a bit of a unique nerd when I was a little kid,
Like my dad got me into like mostly Fedora, right, And for
your dad, that's a parenting win right there. Totally, Well, yeah,
hi, dad, that was a parenting went good job, and yeah,
like he he got me into that. And also I kind of wasn't
allowed to access the internet unless I could, like you know, do some
basic like movements on my machine for a while, and I remember, like
god, I remember like when I discovered flash video and then I was like,
oh my god, I don't have the drivers for this, and I've
spent like you know, hours and hours trying to get up the work.
So definitely always more on the software side. I'm not I'm not a hardware
nerd, and I would say, like I feel like some some deep shame
about that. I just never never really got into it. That's interesting because
it turned into like a I guess, a career, a career in software.
There were some different points at which I was pursuing different things. I
have a degree in English literature, but I ended up getting different jobs and
like like I would be a secretary and I'd be like, your computer system,
really it's really old and crafty, like, do you want me to
fix it for you? And that turned into into a career in tech.
It's been really interesting. In my first real job was first real proper type
job, I would say, was yeah, being a being on the systems
team and ultimately the team lead of the systems team at the University of New
Mexico for Learning Management systems. So that's that was my sisidman job, and
that's where I had the pager and I had to I graduated from Fedora to
red Hat Enterprise Linux and uh, it was it was a fun journey.
And then after that I really understood why, you know, why application delivery
and software delivery was important and what what is this DevOps thing? That's when
I found out about it. And even though I had played with Cloud a
lot, so I also have a master's in Information Systems from Northwestern and when
I was doing that remote a lot of remote classes for that, I was
like, I don't I'm not a hardware nerd. I don't have a machine
that I want to sort of build for this for this purpose. So what
is this AWS thing? And that was like what twenty fifteen, so not
like very early AWS days, but pretty early when everybody was just playing with
it and hadup was really popular. Then she was also playing with that and
like managing my own HADUPE clusters in AWS and trying to like find other people
in the class who were trying to do it. But that was that was
really interesting and then anyway, this is going to be a babble, a
babble past babble alert. But yeah, then I I started working at Puppet
after that and had some some career in DevOps and ended up at Render,
most recently working at working with really a totally different crowd of folks who want
all of that to be abstracted away. And you're right, it's it's not
just passed. Like I think, networking stuff is buried under layer after late
of abstraction and we continue to like actually, was listening to one of your
episodes of your podcast a couple of days ago about a virtual a virtual networking
solution from twenty twenty one, and that was really interesting. But yeah,
like we just we just abstract all the things, but the thing is like
still underneath that kernel is still under there. And also all of these you
know, TCP IP connections, everything is still talking to each other using a
lot of the same protocols. We just have gotten to the point where you
can be a principal engineer and not know what is going on. You know,
you're you're eight layers of software abstraction deep, and you're not that deep
by old, Well, it's very deep. It's like things I don't understand,
right, like a lot of the Kubernetes networking stuff, but like you're
not you're not at that rudimentary layer. So what kent tig is really about
is bridging that, Like, how how do you how do you get the
observability in like, because the thing is like, nine times out of ten,
you're fine having having only that visibility eight layers deep. You're fine and
you know everything. But then once about every depending upon how much infrastructure you're
managing, once every six weeks to six months, you're TCP dumping for hours
and hours trying to understand what's going on because you have no clue what's wrong
with your what's wrong with your infrastructure or why especially you know latency, why
something is and not performing as people expect. So yeah, now that's what
I work on. I was trying to tell you about my background, but
it's, uh, yeah, it's it's a new challenge to be looking at
this network observability thing, and observability is super important. So yeah, it's
it's one of those things where it's it's only important when it's broken, right,
Like otherwise you just don't care. And I think that's one of the
hard parts, is like how do you know what what should I be monitoring
or look recording ahead of time so that when this does break, I've got
enough information to understand which part actually broke. The spoiler there is whatever you
weren't recording, sure well. And then the tricky game with that too is
like and I remember those days, like this one esoteric thing that you need
to be observing, Like next time, you're going to have that data,
but that's not going to be the problem. It's going to be a different
It's like whack a mole, right right, So it's good to have.
And I think that's where that's where really the word observability comes in. It's
like selling this fantasy that you're going to have all of the data all the
time and then you'll just be able to look across with your crystal ball and
observe it all. I think that's the dream, right, that's the dream.
Oh yeah, You'll have like the big, the big TV screen up
on the wall with the really cool looking diagram and when something goes wrong,
then the right thing is just going to turn red for you and you'll be
like, ah, yeah, I've got it. Oh my god. You
like we say that as a joke, but I've literally been asked for that
buy an executive in a call, like I mean more than once. Yeah,
I've I've worked at startups where they set aside some of the money to
buy TVs to mount in the office just for that reason. I'm like,
no, it doesn't really work like that. And today, like, does
that mean you're buying each of your engineers an SR team or even in a
product engineering team a monitor is stick on their walle at home so they can
just glance, glance over it and see what the current state is. Oh
myn my family would love that. It's dinner time, just like craving my
neck to look over there. Yeah. No, well, and actually that's
what's That's what I really like about Kentick, though, is it's not really
I mean, we we have great dashboards. They're all super customizable. You
can put whatever you want on your dashboard and drag the widgets around and it's
very very easy to customize it to make a dashboard that you want to use.
But that's not that's not the core of our product at all. There
needed right, Yeah, oh god, I aged myself talking about that.
But uh, which, hey, that's that's a badge of honor. I
never wall so I don't have I don't have that badge. But yeah,
so I think what the core of our products is really what we call the
data explore and the metrics explore, like exploring your telemetry is really what we're
about. So yeah, like dashboards are cool. And once you've done your
exploration, like after you had that incident where you figured out what you needed
to look at to know what the problem was. Yeah, like, by
all means, put that graph on your dashboard because if it's that again,
then you're going to know and you're gonna be able to see the history.
But really the power of our product is the ability to kind of explore because
because what we're really talking about here is unknown unknowns, right Like that the
unknown unknown is is that's the mill always the million dollar question. So if
you have the ability to ask questions really quickly, get the answer, get
the answer to anything that you need to know kind of in a visual format,
be able to compare it, like compare you know, what's happening in
the last five minutes to what happened in the last even maybe thirty days,
and you can kind of slice and dice that in a way that makes sense
to you, and you can compare and put a lot of different because this
is like high cardinality data like network telemetry, there's a lot of attributes in
that data set. And for Pentich, actually we add so our bread and
by is well, where Kentic started was flow logs, right, So that's
a traffic flow. Traffic analysis basically is was was where Kentick started. But
if you look at a raw flow log, there are a bunch of different
kinds of flow logs in the cloud. We're talking about VPC flow logs,
although they're also called different things but different cloud providers of course for prietory.
But it's a little hard to make sense of the raw log. And that's
another thing. I mean, it's not as bad as PCP dumping, but
people don't necessarily want to be like reading through flow logs, you know,
one after another. But what we do is we enrich that raw log with
like application context like so things like tags for example, application names and a
bunch of other network e stuff that I don't necessarily know a lot about,
but so that you can understand kind of all of those layers and you have
context, so you're never looking it's not like you're using Knick to look at
the raw flolog or now we do metrics to from from cloud and from devices.
We enrich that data as well, so you can kind of draw a
line between between the different data points that you're trying to understand, and you
can do those as a line graph or as a sand key, or you
can look at it in a table. Like there's a lot of different ways
to visualize the data and understand it, and that's really where the power is
because a dashboard back to the dashboard thing. A dashboard is like it's only
as good as what you knew to put on the dashboard, right, and
that is an there there was some kind of meme about being in sort of
a post dashboard dashboard fatigue. I think is there's some memes out there.
I can't think of them right now, but really, like, what what
you really want to do is explore the data and understand it like you want
to you want to be able to find things and that quickly. I think
that's really like observable. The promises of observability goes beyond the dashboard, and
it's really about human It's about harnessing all the telemetry that you can to power
your human brain. Like it's yeah, yeah, it's like there's all of
this information that can quickly overload me. So just take everything that looks like
it always has and ignore that and show me what changed. Yeah, yeah,
show me what changed. Like an anomaly detection is definitely huge in our
in our space because even if you and that's I think that's where we can
make things more accessible to folks who don't have a ton of network engineering background
or passion. It's like, I don't really need to understand the nitty gritty
of what like of what's like what is different here? Just show me that
it's different, and then I can dig into that and I can go and
I can understand that. Show tell me, right, But like that's our
job now, right, That's that's the truth. So so it's really nice
to be able to I guess the marketing term is democratize, uh, to
kind of democratize access to network data and bring it into the bringing into the
twenty first century because a lot of the tools that are are used by by
network engineering teams have been around for a long time and there because this is
old, like this is old technology that hasn't necessarily changed that much at its
core. So yeah, it's important to be able to have observability into all
of these different environments like like your public cloud, like your past and all
that. When or does in the process or do you see these tools being
used? Like is it that there is some sort of alert or some problem
in production my environment? And now I need to investigate further and I'm not
even sure where to start. And then at that moment it's like, well,
you know, while it's so great that I had this tool that was
already ingesting all of my VPC flow logs, and I'm going to it and
reading through what's there, and the anomaly detection runs and tells me about some
sort of network issue. Is that the sort of flow that you think about?
Here? It depends because yeah, good question there. Kentik is a
platform and we have a few different kind of products in there, and so
yes, but high high level yes, there are alerts. So if I
have a faulty device or a device that's having software hardware problems, then I
can get an alert on that I have all my devices onboarded. So that's
like in the data center, right it similarly in the cloud, I can
set alerts on different thresholds. Is actually alerting is very complicated in itself because
there are different kind of schemes for what would trigger an alert, and alert
fatigue is also also a mean and me something you've probably talked about on the
show. So it's important to have a sophisticated ability to set the alerts and
kind of fine tune what is actually on fire and what's not. So we
certainly have that capability for all the types of environments that we provide observability into.
And but so what I've seen, we work with a lot of big
enterprises, and I have heard like, hey, the network team gets called
into every single incident. So every time there's an incident, someone from the
network team is on the call and they need to be. They may get
a question of like, you know, this application stack is experience. It
seems like it's experiencing latency and what you know, what is it? And
the classic question is like is it the network? And there's even like this
sort of idea of the meantime to innocence, which I'm sure you've heard of
I'm trying to resolve themselves of responsibility. But I think that's real because they
really do get called into every incident, and then you know, what percentage
of the time is it the network? Probably not that great of a percentage
of the time, But I think what where we're at now, is that
even when it's not even when I'm doing air quotes but you can't see them
on the pods, not the network. I think the network engine you can
provide insight into because right we're we're in like the world of micro services and
definitely distributed computing. So if I've got traffic going from one service to another
and then the traffic's not going from the next service to the next service,
like, that's information that I can use to understand and zero in on,
like I don't know, Yeah, this this weird, this weird presentation layer
thing is like getting hung up, and here's where it's happening. So I
think, yeah, But the tools also get used for other stuff like capacity
planning. Capacity thing is really important in because right we're not just about incidents,
we're also about you know, providing reliability and resiliency. That that's also
our job. These days, and and and like latency is sort of the
new outage sometimes, I think. So it's not just about like about promoting
availability, but also like making sure that performance is what your customers expect all
the time. We all have very high expectations for that. So anyway,
capacity plane is really important. So understanding like if I do have in my
hybrid cloud infrastructure, if I do have you know, data data requests are
traveling across a cloud interconnect pipe we call it a pipe, then I want
to know, like what's the capacity of that pipe? Am I filling it
up? Like when am I filling up at surges? How do I manage
And different kinds of different kinds of gateways like in the cloud, for example,
have different uh different properties and different performance that I can get out of
those and kind of how I set everything up. I'm always balancing cost with
performance to make sure that folks are gonna get get the get the performance that
they expect at a cost that I can afford. So that's and and and
Because people don't necessarily know very much about networking, even when they're designing workloads
in the cloud, they may have something set up, like with a transit
gateway when or And actually you can see in Kentick, you can look at
things on a map and see like how the traffic is traveling, and sometimes
you're like, oh, it's going out there and then it's coming back in,
Like why is it doing that? Sometimes it might be doing that for
a reason, like it's a it's a firewall thing, But other times it's
just the way that some that some dude set it up, and you can
change that and you can realize performance gains and cost gains from that. So
that's like another place where the tools get get used. Beyond kind of a
learning, it's also about being proactive. I feel like you kind of called
me out there because that was my that's my incident response run book is blame
the network team, and I know it's probably not THEMN, but it at
least buys me time to figure out what's really going on while they're trying to
prove their innocence. Yeah, because that's not a fast thing to do,
right, you know, it's like how do I how do I absolve myself
of culpability? Here is quite the challenge. No, it's true, but
hey, I think like I've I've been there, So that's why I can,
I can. I've never been a network engineer, so I was always
calling, you know, I got an issue with my one of my applications,
I'm calling the network team. And they managed our virtualized infrastructure, so
all of the the sphere sort of infrastructure. So I think, probably what
were they doing when I was calling them, They're like restarting this restarting this
node just to see if it's the problem and watching it fill over, and
so yeah, well they were doing that. I was just, yeah,
desperately like repping through logs and trying to look for a pattern, right because
it could come back on me. For database administration stuff, it was always
it was always fun for me when it was the database because I was also
secretly kind of wanted to be a DBA and study that in school. So
I would be much more of an active partner like I would be, and
I think there was more more information, Like in my application logs, I
could find stuff. I could find, you know, Oracle errors or my
SQL errors that would that would be like smoking gun material. And then I
would go and do these extended kind of research into what was going on because
I could I cared about kind of how they were implemented on the application side
and what the interplay was so so that was I was more of an active
partner on that before the network I was exactly like you weren't just like all
right, uh yeah, like like all of us right, I think we're
all on the same boat. It's like you need that network engineer when you
need them. Real I got so scared, what uh you mentioned the DBA
thing because I feel like there was a non triven number of times where a
DVA DIDs down and be like, oh you know what, we know what
was going on, and we ran something and it fixed it. And I'm
just like I don't want that to be the answer. Oh yeah, because
you want to, you want to be the hero. But then the thing
is the alternative. The alternative is potentially that like if it really is your
problem, your problem on the application layer that you or you know, even
the OS layer was for in my book, in my experience, like if
it really was my fault, it probably literally was my fault, like it
was some kind of typo that I had made during an upgrade months before.
And then like I go in there and I find like, oh god,
like there's a carriage return there that's bad. And then I mean, do
you really want to be explaining that. Probably not, I'm amazing. I
feel something about it for me that feels justifiable, though, Like I could
be like, hey, look there's a typo here, clearly that's causing the
problem, and you know, my change and everyone can look at that.
But when there's a problem on the network side or on the database side,
and there's an issue there and it gets resolved somehow, I know having been
on the other side so frequently that I honestly could not grock what they're telling
me, Like what the what the fix was adding extra nodes or replacing them
or something about the routing is very difficult to understand. It's true, and
you wonder, you wonder, like is this going to be another sleepless night,
Like is this going to happen again? Because sometimes we would have that.
It would happen once and they would be like, we fixed it,
we ran this thing, or we restarted this thing, and then like two
weeks later it happens again and this time it's faster. They fix it.
But yeah, no, you're right, I get it. It's I mean,
this is all it's all part of the thing, and you're talking about
root cause analysis, and I think like what we talk about a lot at
Kentig is sort of this holy grail, and that is you know, I
how far are we into the conversation. We're twenty four minutes, twenty five
minutes into the conversation for the record, and I am going to utter the
phrase AI, right was going to come up. I can't believe I got
twenty five minutes into this call without uttering the phrase AI. But yeah,
but look our live subscribe account just went up to yeah. But I mean,
really, that's that's the that's the magic, right if you can get
something that can do some of that for you and say, hey, that's
probably it. Why do you check this and let me say it like that.
It's not I do not think that we are close to having a distributed
computing experience where an AI, you know, an AI bought can say it's
this, I'm going to fix it now. That's not what it is.
It's really about like that that bot still has to talk to Tier three,
right, Like we are still tier three and we need to be able to
look and see. But it's really just about making that faster and saying,
hey, there, you know there is a carriage return here in this script
and there shouldn't be, and if you fix that, it'll probably it'll probably
resolve this. I think that's kind of the that's the that's what everyone's sort
of working towards right now. And I think different different companies are different to
our are further along and different certain disciplines. It's easier to get get further
along because automation has been part of it for a long time, so it's
easier to kind of get there. But for us, where we are at
is if I, you know, I say, we can answer any question
about your network, the networks you own or the networks that you don't.
That's true. And now we have a quick your assistant, and we have
an interface called Journeys that allows you to essentially have a chat GPT like session
with Kentich where you say, hey, you know, compare the bandwidth like
on on on these devices over the last month and show me or or you
know, what are my what are my top consumers? You can ask any
kind of questions, show me that my devices that are in this region and
what are the status of all of them? And sort them by you know,
you can do all of that and and instead of doing it in our
guy, in our guy data exp like I was describing earlier, where you've
got to, you know, find all the attributes that you care about and
check them all. When you have like such high cardinality data and you have
like a heavy ability to manipulate it, it's a lot of checkboxes. It's
a lot. It's kind of a lot to look at, and it's hard
to create a UI that feels really easy to use. But I think the
the chat, the natural language natural language query of facility really helps us like
do that data democratization right, because you know you will. You're afraid of
the network, but you probably know what kind of question you have. You
could start asking, and then the query assistant in the journey especially, you
can look back and see, like what questions did other people ask, because
like we said, sometimes it's the same thing again that happens, right,
So if you want to go back and look at what query's folks made before
and what the so they started with this question, but they finished their session
and they answered the question here at the end. That was what really led
them to understand what was going on. You can look back through that and
see you know what was that root cause essentially, and then I think the
next step of that for us is suggesting what questions to ask next, suggesting
what the root cause might be. You know, when this problem shows up
a lot of times, here's the answer. So that's what we are working
towards. Yeah, and I think you said before it's about finding the unknown
unknowns, and I feel like that may be something where AI helps us a
lot there in discovering those. And I'm sort of curious if any interesting things
have already popped out that wouldn't have been so obvious either if you were looking
at the dashboards yourself or had to create the queries yourself, because that sort
of goes in the long lines of I already sort of know what the problem
is, but I want the data to prove it. And I think there
is this challenge of well, I don't even know where to start. Give
me something, you know, suggest to me something, and maybe I'll pull
at that instead. Yeah, we definitely have kind of a splash page with
a bunch of sample a bunch of kind of sample queries on it, so
you can just click and get started, like, Okay, I'll jump into
jump into this and vestigation. I don't know if I have any stories of
like the the unexpected of findings, but that's a really good one too.
I mean, we were talking a little bit about marketing. That's a really
good one to dig up. I think this is like, you know,
how long would it have taken you to figure out that this is the problem
or how long would it have taken you to observe this difference? I think
I would say for kent Tick though, there are a lot of very talented
network engineers who have been using Kentick to dig into their flow and their metrics
for quite quite some time. So I would I would hesitate to say that
AI can find anything that they can't find, because I think like a super
user of kent tick is still far more powerful than an AI bought of kentig.
But together, like together they can be unstoppable. The idea, Yeah,
but I will look for that. And so that's one of the areas
where something like kentik and can help out. Because we've talked about how what
we talked about how like you know, some of us have like really not
putting myself in this group, but there are people who have like really really
deep, long areas of expertise, and you know, like as I get
older, I kind of feel like that's more and more of my job is
to distill what I've done over the last thirty years so that people entering the
industry right now don't have to relearn all of that stuff. And I think
that's one of the things that like companies like Kentick do is it's like,
hey, based on all of this stuff that you don't know about, here's
this thing that you might want to google. Yeah, yeah, no,
I think that that's that's going to be. That's going to be where this
really has legs. I mean, it's really nice to be able to explore
the data in natural language and you can ask it in any language you want.
So that's helpful even for like to sell folks on your team as we
get globalized. So I think there's like a lot of power just in the
entry level of equery assistant. But yeah, where there where the where I
start to drop my AI skepticism in earnest is where it can say like,
yeah, you you are you know, because like we said, if it's
a different problem every time, you really do have to work on this for
twenty years to see like a full range of of what it could be.
And for these folks who are dealing with you know, heterogeneous infrastructure where they
may have some really old legacy applications that they're maintaining or you know, we
call them legacy applications. They have some applications that are still working, still
making money, and they don't want to change anything because and the bosses don't
want to change anything, right, And then they have all this new infrastructure
that's getting built and they're they're running workloads on Kubernetes and this, so they've
got containerized stuff and they're also doing serverful stuff and they need to like keep
track of all of that. How can you hold the context of all of
that in your mind? And I think that's way beyond what any of us
who were kind of doing things in the old days. I think it's very
different now. I think that they have a lot more context to keep track
of. So what I'm really happy to hear you say that will that that
that's your goal is to help them. It's essentially a shortcut, right right.
Yeah. When I think about like old school OPS culture and definitely old
school like Linux culture, it's a bit you're smiling. You're smiling. You
know what I'm going to say, Right, it's not that it's not that
it's not the most welcoming environment, or it wasn't I should say it wasn't
the most welcoming environment. Yeah, I think it was a lot of Like
I mean, you can it's all over stack overflow if you want to go
to stack over It's like people are like, I can't belie leave you would
post that, like, you know, people very rudely explaining how it's just
unacceptable to post such a question without posting your entire you know, and like
don't post your entire log trace in here, like to cut cut through,
like show me that you did the research yourself, right, you try to
understand this yourself and then I will help you. And that there's really like
a tension between that cause I think that that definitely, like the potentially discourage
meant of asking questions is of course also part of old school network engineering culture.
There's a lot there's a lot of similarity there, and I think it's
really the same culture. And then there are but there are people like yourself
who want to benevolent folks who want to pass along that knowledge and kind of
be greater than the sum of our parts. So as a as a marketer,
I feel like I have to sort of appeal to like I have to
appeal to that culture that that where credibility and like doing the legwork is really
valued and really important. But at the same time, like I mean,
the the boss doesn't really want to pay for the legwork if it doesn't need
to be done. If your pains or your talent, then you want to
get you want you want that talent to spread around the team. You don't
want to be siloed into one person. And then also there's this new I
think. I think Kubernetes was a huge part of that sort of transformation from
the from the old culture that you were talking about to the new culture.
I think the way that the Kubernetes community like came up and then was managed
has been a huge part of that. Do you think so are there other
other factors? Like why why are those answers not on stack overflow, not
not getting on stack overflow as much anymore? Like what's changed? I guess
my question. I feel like right around the time that Kubernetes came out,
there was like a pretty significant shift of people. There was like enough people
who found each other online that were tired of that type of response, and
I think it came together in several areas, Kubernetes being one of those.
But one of the things that continues to make me laugh is whenever they said
that chat gpt was trained using stack Overflow answers, I was like, oh,
this should be good, I mean, great, brilliant, but also
wow, chat doesn't ever scold me. Though I don't think I've ever been
scolded by chat GPT. I mean, I think maybe not chat gpt itself,
but I do recall some of the other lms giving responses through some of
the other websites that may have been using the same underlying model about that they
were wrong to ask the question, and then when saying like it, and
there was a whole back and forth about it, and really just over and
over again saying no, no, you have no idea what you're talking about,
even though clearly like everyone knows that the person that was chatting was right,
but the blot was definitely confused. You actually said something super interesting that
I don't want to gloss over, is that potentially the problems that are being
solved today are actually more challenging, they require more contact than they did in
the past. And I sort of want to pick your brain on that a
little bit, because that seems like it's really interesting that maybe it's possible that
the problems today are more complicated, are more difficult to solve, and that
we won't be able to do it with the same tools that we've been utilizing
up to this point. Yeah, I mean, I think I think to
clarify there, maybe the individual problems themselves are still like when you do know
what the root cause is, maybe that root cause is no more sophisticated in
nature than like a problem of your But I think what makes it, what
makes it more challenging, is just the I mean, we're talking about cardinality
of data, and it's really it's kind of it's just like the volume of
different like the probability that it would be any one thing is so much lower,
I think because of the distributed nature of our systems. But then it
is also it is also when we talk about like things things, when I
talk about things being so software defined, I think that also adds another So
maybe there is more complexity introduced by like the programmatic nature of so many things,
so you can have like like is this really a problem with a thing
that I'm trying to manage, or is it a problem with like the way
that the thing that I'm trying to manage is accessible or is administered. So
I think there's just all of those layers, add add more automation, but
then also add like the potential for failure. And I think part of it
is also because are we ever using things exactly as they were intended? Like
when you design a product, when you design a tool or a platform,
or design a piece of infrastructure, you're oftentimes thinking about doing it, you
know, in a specific context. And then when you take those things out
into the wild again heterogeneous plan they're trying to they're trying to kind of put
it all together, right, trying to trying to connect connect things together and
integrate different systems. And that's where I mean, those are like the longest
Googling sessions, Right. You try to you try to, like you try
to interface one thing with another, and you think it's You're like, well,
this could go one of three ways, Like it could be super easy,
the exact way I think that you're supposed to do it. It could
be like this middle way where I have to try a few things, but
it's one of these answers that are on the internet, or it could just
like fail kind of silently and I don't know why it doesn't work, And
then I'm kind of stuck and I have to figure out like do I need
to figure out a different way to integrate these together? Like is this not
going to work? I need to figure out when to cut over and give
up. And I think there's there's just more of that now, right,
Like they're more potential for that for that to come up. I would you
agree? Yeah, I mean I think you really hit on something with the
volume, where in the past just the number of requests you'd have to any
individual service is such a low number. With the number of users you have,
that's still providing a ton of value. You could go through the logs
manually, right, you know, you think about your own operating system,
you can go to the cystlog and see what's there or whatever you're using and
actually see what applications crash and what the log message are, you know,
if you're debugging locally. But when you talk about the production systems now today
in twenty twenty four, yeah, I mean you're not going through that manually.
Now. I think we're at a point now where the level of abstraction
is so high that it's really really fine line between whether we are software engineers
or whether we're Rube Goldberg engineers. Were integration engineers for sure, one hundred
percent. Well, you know you're right there on that. Like most of
the things, most of the time year spending out there is connecting components together
to deliver the value. You're not designed. I mean, you could be
on the cutting edge of designing the new silicon or even the LM model today,
but like lots of companies have spun up your building on top of that,
which is hundreds of layers of abstraction. Deep. Yeah, and if
it's not working, it is that thing of like not knowing where to start.
I can't let it pass that, you said, Rube Goldberg, Rube
Goldberg machine. When I worked at Armory. When I worked at Armory,
which was a proprietary distribution of US spin Occur, the continuous delivery tool developed
at Netflix. I was there. What was I? I was director of
open source and really like an open source DevRel person, and I had this
brilliant idea that we would buy this. The culture there was very like pend
money on the things that invest in the things that you think would be good
for the company, and like you're empowered to do that. I was like,
I feel empowered to build a very large roof Goldberg machine and you are
going to cart this thing out to every event, Like we're gonna go to
AW. This is going to be our big AWS reinvent bid where we have
a giant rube Goldberg machine and then we do demonstration. I still think that
would be fun. Now somebody's going to listen to this and lift that idea
who has a much bigger budget than I do. But you know, it
really is about it really is a Goldberg machine, like it really is,
And that would be great to go to AWS or reinvent or whatever and just
see a big, huge roobe Goldberg machine. It just goes all the way
up to the ceiling of the auditorium. Yeah, and then it's like,
ah, I mean probably this is canceled. Maybe, but like I think
about Pee Wee Herman and the opening where he's making his breakfast and the egg
comes in this thing. What I'm telling you marketing gold marketing goal that,
but it really that was kind of the message. It's so funny because if
the message was the same there, it's like we have all these sort of
riddle we called it brittle. It's another marketing term, like your brittle path
to production sort of how we talked about it. And sometimes it really does
feel like a rut Boldberg machine. And I think, I think when I'm
looking at that from the observability perspective, it's really the same visualization. It's
like, yeah, you have this bespoke way that each one of your applications
is getting these very basic communications across like to and from the user and and
getting the data and making getting getting in you know, doing the the the
crud on the data in a way that's secure. And there's actually a lot
that goes into that. But really, like it does feel like a root
Bulber machine, I think. But it's all was still the same stuff.
So it's just interesting how it's more it's it's more more abstraction over what are
fundamentally the same types of interactions. But but what has changed a lot is
the user experience. Right, Yeah, for sure, we've gotten the entire
planet addicted to an impeccable user experience and that's that, and we can never
come back from that. We now we get it. I wish that were
the case, but I still feel like I see some UIs every every day.
That made question who is running UX over at that any government website?
Oh yeah, well yeah, that's all I mean, government healthcare. It's
like yeah, and it's but it's actually like it makes me think about So.
I once interviewed with a company that made software for planes and they told
me about the sort of the I I ended up not taking not taking this
job, but it was really interesting and they were like, we have been
we are such a like pioneering company in this space because we've figured out that
if we can run the software on a tablet, like we can run the
software on an iPad, then we're able to get around so much regulatory stuff
because but the PSA has rules or no that at Federal Aviation Administration has all
these rules about what is physically bolted to the plane. So if something is
physically connected to the plane, then it has to go through literally years of
like safety safety and regulatory process to check to make sure that it's safe.
But if your software system is not physically connected to the plane and you can
like lift it off. Then they didn't have to go through the same regulatory
procedure. And I thought that was so fascinating that they were like, that's
why airplane systems are so far behind, because they are not, like they
can't. So if you want want to change the UX right, it's going
to take you like five years. So that's why I think that for government
stuff. But I don't know. I think for government all a lot of
times they just don't put the money into it, and they don't it's just
not a priority. Well I mean, I mean, I think we know
that there is definitely money going into it. It's just you know where the
mondy is going is it's an episode on its own. It probably a watch
list somewhere if we have. Yeah, I just maybe that's a bad topic.
You know, I've worked in a lot of different industries that have varying
degrees of regulation. There is definitely something to be said about the amount of
regulation and the length of the feedback loop for improvements, for sure. Yeah,
yeah, I think that's that's part of it. But but yeah,
you said people aren't addicted to great, Well, people are addicted to great
UX but you still have to find it right to go and find those tools
and platforms that have that that have the space that you want. I don't
know. I think if I think about though, like how much things have
changed in the last decade in terms of just what could like what consumer expectations
are, I think, uh, I think it has changed a lot,
and I think a lot of people have worked really hard on making that happen.
So it's pretty cool, yeah, for sure. I mean we are
very much in a position where our expectations are you know, millisecond latency from
from applications, and for the most part, I feel like our expectations are
rarely not met when it comes to that, and that's a huge amount of
effort. And under the cover's work, you know that you can hit a
vast majority of the websites and you you click the button and it makes a
call to the back end API and returns the data and in a millisecond time
frame, and tying that back to what you're doing. The layers of networking
that are happening there is just really tough to visualize, much less troubleshoot whenever
it does breach that one hundred millisecond threshold. I'm not breaking anyone understanding here.
There is actually some resource posts that the research says that the more effort
that a user puts in to having an action executed, the longer they actually
expect to wait. And if you respond too fast, that they'll feel like,
wait, I don't understand how could that be the case? So like
this actually does happen. So we internally actually especially in r UIs for authors,
we do actually measure the amount of expectation for the effort that a user
should have to put in for those things and figure out like what is their
expectation going to be for how long that activity takes if they expect that thing
to happen really fast, and those make it into our slas. And for
things that actually seem like they're super complicated, well there is a little bit
of fudging that we have to do there is to make it seem like that
they get the appropriate thing, Like there are intentional weights in some situations to
make because it's too fast, you know, we respond in like one millisecond,
they're like, I don't understand how it can be that fast. That
doesn't seem right, So you make it wait a little bit longer, and
like it also has a UI impact though too, because if you make an
action in the page would refresh or something like that, afterwards, you don't
have any time to say, hey, your thing was successful. So actually
delaying that has a much better user experience than just immediately performing the next thing
in some circumstances. That is really interesting. So that's really like we're almost
hitting the threshold or something like hating the threshold of human like human computational power
or something. I'm going to have to reach out to my buddy on our
product team who have been working with who is putting out our network monitoring system.
So network monitoring systems, you, I don't know if you fuse them.
You may have used some of the free ones like Libra and MS.
Everybody has one. An everybody with an on premise network device of any kind
has some kind of thing that's going to tell them if it's up or down
right, and they almost all network monitoring systems are really old and crufty,
like they're your federal website version of a tool. And that's like, actually,
so we put out this new network network monitoring system that we released at
the end of January and it does have it. It has the query as
system that I talked about before built in. But it's really interesting to try
to write marketing copy for this and figure out how to sell it to people,
because really what we're selling is like you know, no, no,
no, we haven't really like yes we have we have like a data explore
metrics explorer that lets you explore all these unknown unknowns we have AI. It's
a SaaS tool and that's all exciting, but also under the covers it's doing
the same thing. It's pulling your devices to find out if they're up or
down. But anyway, one of the you just made me think about one
of the things we talk about as a selling point is browser refresh is not
required. So like we're literally like selling that it's a responsive uh, that
it's a responsive app. So if my if my device gets if I'm onboarding
a new device and I'm waiting for it to finish and then it and then
it comes up, that's just going to happen. I don't have to refresh
the page. But really, so going back to our conversation constantly, going
back to our conversation about incident, if you have if you think about a
network person trying to like they they it was the network, right, They
figured out that it was this device that was that that was heaving a problem
that was had a hardware or a software problem usually and they go to fix
it, like they go log into the device and reset it or something or
change threshold, and then they have you have to wait to see if it
works, right, like before you can go back to flee or go back
to your regular job. But we all sometimes before you can go back to
sleep, you have to see if it works. And so we have this
image and I really want to make an ad for this of just someone just
like refreshing the page, refreshing the page, refreshing the page, and they're
looking to see like for that change. So I think it's definitely a fine
line, Like you're right, it could be too fast, but there are
a lot of systems out there that are nowhere near too fast. And we're
so. But it's funny because my colleague, my PM colleague is like,
I'm like, you know, we're got to saw that it's a SaaS tool,
and I think I put on a I put on something the other day
SaaS Innovation and he was like, don't say that you know, SAS has
been around for a long time. I know, I know that, but
it really is innovative in this space. So it's just it's funny. I
think the point here is like it's all relative, right, But it is
nice when you need to use a tool, like you have a tool like
a like an NMS and you've got something like you've got to monitor those devices,
it's nice to have a it's nice to have a platform that doesn't make
you feel like you're living in you know, I don't know what you're two
thousand and four that may be even still too recent. I mean you made
me think of like every router software that that like not only do you need
to wait, but it tells you do not refresh the page because if you
do, like I am afraid that it will brick itself. It's gonna it's
gonna somehow lose your request it refresh the page. Yeah, it was like,
what what is it doing? Is it? It's just like, what
what is it doing? Honestly? Like and then it tells you if like
another admin logs into the router at the same time, like I'm sorry,
only one admin can be logged in at this time. It's like Okay,
I mean fine, just tell me just me read only mode that right,
like you know, let me see the data, but don't change it for
whatever reason. No, totally, So you can see how this has been,
like the this has been like selling a network monitoring system in twenty twenty
four. Is it just about the un sexiest task that a technical marketer could
have, right? Like it is not Like we are not and like you
you mentioned SNMP traps at the beginning, we actually came out with this tool
and we're like we we're not gonna support SNMP traps because you know, it's
UDP and it's not very secure, and we were were a little uncomfortable with
that. But as we've gone out into the field to talk to folks about
this tool, and we've onboarded like some huge enterprises into using this tool,
and we've found people out there in these conversations who are like, well,
I'm using SNMP traps extensively and it's essentially but like you know why they're doing
it because it's event Like it was really really really early implementation of essentially like
event based monitoring. So the device has an event and it can go,
oh hey, I'm having a problem like that was cool, right, and
it still is cool and a lot of people are really relying on that,
but for us to come out and say, well, sorry, that's too
crafty, like we are not we are not going to support that because we
do not try like we can't do that. So we have to build the
support. We have to build the support, and we have to find a
way to build it in a way that will that will be that we that
we can feel like it's secure enough to give over to our customers, but
they can feel like it fits into their workflow. So anyway, that's a
that's a digression from like the browser refresh thing, but I think there's a
lot too like that. It's been a fun marketing challenge to try to to
try to market this tool that's been around for it's been around for twenty five
years, right. I mean we actually did something very similar in our space
for so we offer off for oursas and we started by saying, no,
we're not going to have passwords support by default, like the this is this
is absolutely technology. It's insecure by design, there's no there's no fixing that.
And we wanted the B two B market and it's been fine. Uh,
it was fine for a very long time, and then we started getting
customers who wanted to go into B two C and have end users that didn't
a sophistication. And so we've created a clear separation in both marketing and how
our docs are written to be clear like, hey, if you're in the
B two B context, like you really don't want to use this, like
look at the research. It's going to tell you why, there's no reason.
And if you're in B two C, you know, maybe there's not
anything you can do about that. Yeah, no, I think that,
Oh gosh, this is the worst term. But they call that thought leadership,
right, you're educating, educating your customer. That's what really makes me
want to bar But I hear people say every day that's the worst. But
anyway, No, you're educating your customers about like, hey, you know,
and I think I think that's valuable. I think I think technical folks,
like when you're shopping for a when you're shopping for a product, you
do want to know that the vendor that that that the vendor you're working with
is opinionated about the right way to do things and has really thought about that
at scale and looked at how other people are doing it, like you want
those best practices because again, when you're trying to navigate this through Goldberg machine,
there's a lot there and you don't necessarily know what the best practices are
for everything, and like everything else, you got to google that and you
know, and it's good to have a trusted source for that. So I
think that's the right way to I think that's the right way to handle that's
just be really honest about it, no, for sure, because otherwise you
don't really have a differentiator, right, Like anyone can write the technology that
you don't see the service that's running. Anyone can hire the right people with
enough time and effort and you know, maybe even get funding. I mean,
like where do you differentiate, right, It's going to have to be
on the way your company mindset or values really really operate. Yeah, it's
really what's left there. Yeah, totally all right. And so that's a
great segue into the topic that I wanted to talk about here because a lot
of that, you know, you're talking about implementing a cultural change, you
know, like the S and MP traps. Like someone who says, hey,
these S and MP traps have been rock solid, reliable for me for
twenty five years. Why am I going to change? And so you have
this this change that you have to implement which goes into marketing. And I
really think that that's like an unspoken skill that successful engineers have, is the
ability to understand marketing and know how to introduce these topics and like convince people
to your line of thinking. So with your background, Roslyn, your role
is marketing to technical people. So how do you you know, for just
at the risk of saying something stupid, because that's kind of my role here,
how do you make your marketing content nerdy enough to be believable? Yeah,
No, that's a great that's a great question. I think where it
starts is you really have to have the right and I mean not I'm not
saying I'm the I'm necessarily the right person, but you you have to have
We have a whole content team actually of people who are like, Okay,
if you're a network engineering nerd, which you're not, you'll know Doug Madori,
who whose director on our on our content team, who is like gets
called by the NSA and by other federal, federal and international agencies to do
like tracing traffic, uh for like to help with global like geopolitical stuff,
like he's the one who goes and looks and understands what what Russia is doing
with the networks in Ukraine and so uh that's an extreme example, but we
have a variety of like folks who were in the field, like we're we're
kind of wearing the wearing the shoes of our customer and those are the people
who write all of our blog posts and they sort of promote the brand and
me, so I I sort of had some shoes that look like, you
know, look like I had some systems engineering shoes at one point. They're
still in my closet, but I don't wear them very often anymore. And
you know, like those skills go away. So but with someone like me,
like I, I write what I'm gonna write, like I write what
I'm going to communicate to customers about a product, and then a lot of
times I will So I mentioned my product manager colleague working on that network monitoring
tool. He also had his sort of network engineering shoes that he put away
much more recently, and then he worked at a very prominent network monitoring company
before he came to Kentick, So he's really like just like dug into the
space and he is like my sounding board for all this marketing stuff, and
we really we call it go to market, like we we collaborate on stuff
together. So I think it's really about you mentioned like an an engineer who
has the skill of understanding marketing and being able to communicate that across to their
team and bring folks along. That's really important. And I think that's the
skill that when you're working on marketing in a B to B company for a
highly technical product, which I have now done at a bunch of different companies,
Like cross functional collaboration is the name of the game if you can get
because you've got your people in the field right, especially if you're working at
a company that sells to enterprises and it's a bigger thing. I think this
was different for me at Render because we were more of a a B to
B company, but a bit more of a direct to consumer model because people
just go on to Render or Forroku and they like set up their services and
they're sort of self serving. So that was a bit of a different model.
But now I'm back in this sort of enterprise selling model. Where you
have your sales folks and specifically sales engineers and solutions architects who go out into
the field and they're knee deep in those customer problems like they're inside the root
Goldberg machine trying to help the cutomer find their way out, and so they
really can see like those themes. So sometimes having some of those people react
to your work, but it's for that, it's more like listening. So
I go on to our gong calls, like I listen to their conversations with
our customers. I listen to the words that customers use to talk about their
problems, and I look for patterns, right, and then when I think
I've found the patterns, then I take those two my product manager colleagues or
my or my my colleagues on the content team who are more technical than I
am, and I say, hey, like, how does this land with
you? And sometimes it lands really well, and sometimes they have ideas,
and then I got a massage those ideas. But then what's interesting about it
is like, so we just came across this with a product that we're well
really all all of our products trying to work towards this, Like you have
your I call it practitioner messaging, and then you have your buyer messaging,
and they're different, but also in our feet, well they're not that different
because most of the buyers used to be practitioners. And there's that credibility thing
we talked about, that line of like credibility I think is still really important
in our field, and like you can't be a buyer for a highly technical
system and like run a highly technical team if you don't if you if you
don't, if you don't like demonstrate that those shoes are still in your closet,
I think you kind of need to like have that badge. So I
guess my short answer to your question, which this is not short at all,
never is with me, but my short answer is like having those having
had those shoes in my closet, and like I call on that, I
call on that a lot. I play that card a lot. Like that's
a I think critical to like my ability to be in this role. But
it's also important to like bridge that with the higher level sort of value messaging.
And you mentioned like that bringing people engineers, having a skill of bringing
people along. I think that's a skill to give them too. It's be
like you know this is really technical, and you're in the weeds and you
really like this solution and I want to sell it to you, but you
need to get budget for this solution, and you need to explain like how
it's going to impact your bottom line. There's really only a few ways that
can Like there's really only a few ways to sell a product to a buyer.
Right, It's either going to save you money, or it's gonna save
you time, which is ultimately going to save you money, or it's going
to give you a better, a significantly better end user experience, which is
going to make you more money. So it's really just all about the money.
And like helping them understand that, I think is really like helping them
understand and giving them I mean, they understand it, but that's that's condescending,
But like giving them what they need to be able to communicate that in
a way that they feel like doesn't make them want to barf. I think
that's another like thing that a that a technical product marketer does is like empowering
people to be a champion. Right, Yeah, so like one the once
they have signed off on a technical solution, giving them the tools to make
the financial case yeah, yeah, like once you've got because with Kentick,
like people are I think we definitely have had sort of a what I would
think of as a bottom up sales motion in that like network engineers freaking love
can take Like there are network engineers out there and we have this where like
we'll have a we started in the service provider market, so we have a
ton of customers in the service provider market, and a lot of network engineers
will work at a service provider and then they'll switch over to enterprise and different
challenges. But there's a lot of the big enterprise are basically running big enterprises
are basically running their own service provider internally to meet their network engineering demands.
And so we'll have people who switch over and if they've used Kentic before,
like they're going to want to use it again. So that helps. And
like you have to have both right, Like you have to yet you have
to get the practitioners to fall in love with your product and want to use
it, and it has to be sticky. But then you also have to
make a business like you have to be able to make a business case for
it because otherwise you end up like I mean, I said, I worked
at Puppet Puppet, you know, sad story used in so much of the
ninety percent of the fortune five hundred or something like that, and they were
never really able to monetize it. And Docker is the same story. Right,
we still use Docker everywhere, but they couldn't make money off of that
because they didn't make that business case. And I think that's I mean,
that's a whole other episode of the podcast too, but like that's to me,
that makes me sad, right, it makes me a little sad because
what a great like what a great product? So yeah, and both of
those specifically, like every time they try to make a change to where they
can actually make enough money to operate the company, we go out of our
ways to find out how we can continue using that tool without having to pay
for it. I know, I know. And that's but I mean that
that's okay because a lot of this, like all this all this transformation in
UX that we were just talking about, that's really just been a huge wave
over the last decade. I think it's all built upon free, open source
software, right, Like it all starts with the kernel. To me,
so because I'm not a hardware nerd, but like, uh, it's all
so we can't It's not like we can we can be like, oh,
we're I was going to say a holes, but we can't say we're jerks
because uh we you know, we want to use this free software Like no,
I mean that's in our that's in our DNA, right, Like,
well, yeah, we want to figure out a free way to do it.
So it's like you gotta that's a balance, that's a that's a balance
for And that's why I really like product marketing where I work, because you
get into some of that we call it packaging, right, like how are
you going to package your products so that you're giving away for free what's really
valuable for free? And that makes the customer want to use it, But
you're also like setting your boundaries around your product like this, this is like
this is their goal and and here's how we want to like here's how we
want to monetize that. And I think that's like a fundamentally like an unsolved
problem like how to how to do that well? And and you know vc
VC money has been an interesting like right, like so this this last decade
of UX growth has also been a decade of incredible venture capital investment in technology,
and like, I don't know, I saw some articles about this a
couple of years ago, like just just all the things that we think that
all the things that we think are cheap, like taking a I remember when
Uber and Lyft like raised their prices and it's like, yeah, like this
is how much it actually costs. But before this, you, like,
your experience was being subsidized by a venture by various venture capital firms. I
mean that's true. So figuring out like how to how to transition into this
next phase of the economy is also part of that. Anyway, this is
a huge digression from your marketing question, but now it's really not because like
the same like for me, the way I approach things is like the same
rules still apply there. You know, you can use the subsidized Uber subsidi
subsidized with VC money, which makes Uber look like a cost center that applies
directly to your DevOps team or your network team that you work in in your
day to day job. You know, you're viewed in the company as a
cost center. But if you if you approach it from a marketing perspective,
then you can change the perception of your team from being a cost center to
being you know, a value for your company. Yeah, And I think
that's challenging because for network specifically, because it's so to me it feels like
the very bottom layer of what we think of as the stack, and it's
so ubiquitous at this point that it's really seen as like a utility, right,
It's like a utility. So it's really really hard to make like it's
a very tempting thing. Actually, it's really interesting. We had this conversation
internally really recently. It's really tempting to just market everything based on like,
well, nothing works without the network. So like I'm selling you this new
network monitoring tool and like you know, you're really important, nothing works without
the network. Make sure you say that in your meetings, like well I
need this new tool because nothing works without the network. And I think like
what we've found is that that doesn't always that doesn't always work because it's just
too but it's so fundamental that it's now just part of like our conceptualization of
like you know, I expect for there to be a toilet, I expect
for there, I expect to have water, I expect to be able to
charge my device. And that's just like the way it is, and so
yeah, how you make that transformation from thinking of something as a cost center
to really like feeling the value in wanting to invest in it. I mean,
I think when it comes to the network, where that where that comes
in is like the digital experience, right, So like talking about talking about
what we were talking about in terms of like how the how the network performs
really matters to your to your customers, really matters to the people who are
accessing your services and more. And you have some interesting points that like it
goes that goes both ways, right, it matters to them, It matters
to them both ways, and you have to design around if you have a
really high performing network, then maybe you need to design around the way that
that interaction appears to the user. That's really I never thought about that before,
but yeah, I think that's where the value comes in, is thinking
about that end user experience. But also the sort of hug ups hug ups
sort of strategy comes to mind too, Like I think you need to balance
that, Like Hay, network engineer, I understand you're you're always like you're
often being blamed. It it's it's it's meantime to an instance, for you.
You've got to be in all these calls. You've got to defend the
fundamental like primacy of your service and how critical it is to the entire business
running. But at the same time, people expect it so much that you
don't get the credit, Like you gotta you gotta put those hugs out there.
You also have to be like but yeah, like if you were I
mean, if you, like, if you can be better at your job,
then like people are gonna have a better experience if you can have the
tools that you need to, if you can have the tools that you need
to to raise the bar, then like that's gonna be good for everyone.
So it's kind of like it's it's a hug and a hugging a nudge or
something. It's a it's a bro huga. Oh there it goes. I
don't get a lot of those go I mean I need that. I need
that to me. I think there's an interesting corollary here too that you that
you touched on a little bit, was that going and performing the marketing or
content strategy requires understanding and I think that's twofold there, right, Like not
only it's good to know that that that is a good expectation to have.
But if you are on the technology side at hands on that there is an
alternative paths out there that that your skills, if you like to communicate,
if you if you like to talk about this, if you think you can
uh work with these other teams, either side by side or or with them,
because actually I think this goes into education as well. You call it
thought leadership, but you know, even if you're even if you're a direct
contact, you know they totally get it. They haven't spent much time actually
thinking about how to convey that effectively to not just their executives who sign the
approval on the product, but they are all the rest of their teams.
Like I feel like we get lots of engineers in who are like, we
know we need to do something. Do you have docs on how to do
this or how to do that? Because we may not buy your product,
but wow, this is such a huge problem for us that we would love
to, like, I need to teach other people about how to solve this
issue. Yeah. Yeah, Oh and that's huge. I mean that's kind
of like the developer advocacy angle. I would say that, and I think
that plays super well with and I think this is also like another sign of
the culture change that we were talking about that came around the time that Kubernetes
became became so abiquitous. It's just like people people like the idea of like
sharing, sharing their knowledge and like building each other up. I think that's
really I think that's really like a great way to go. And as a
company, if you can demonstrate that you are willing to spend time, energy,
spend your resources on like building the core competency of the community so that
they can, you know, like what Will was saying, passing that knowledge
along so that the next the next generation of engineers can really like start where
you like be up on your shoulders, right. I'm coming up with all
kinds of metaphors to describe this, but it's like, I think, if
you can truly demonstrate that as a company, that's one of the best,
one of the absolute best ways to appeal to to a developer audience. And
I don't know just one thing to say on the marketing front, you mentioned
like this is like an option for folks if they if they want, if
they think that they can be good at communicating about this, It's very nice
to hear that two of you talk about this in this way and acknowledge that
this is a hard problem, because what I've found in my career is that
a lot of technical folks believe that marketing is like a thing that anyone can
do, like because it's like a soft it's like a soft skill set or
something. And they're like, oh, you know, I could, I
could do that. I just choose not to do that, right, Like
I'm choosing to be a technologist or I'm choosing to be a CEO or whatever
they're choosing to be. But they're like, oh, you've chosen this path
of marketing, but like, really, I could do it better. But
then when you sit down and I think I was probably that person, Like
I ended up in a marketing job, as I think I told you,
by accident, Like I did not. I wasn't like, oh, I'm
going to go on this great marketing career dive and see, you know,
this is where my talents really lie. But I think I was one of
those engineers who was better at like the cross functional communication part. I ended
up doing a lot of that. And then a product manager that I was
working for was like, you know, there's this job opening and I think
you'd be really good at that. Have you ever considered being like a being
a technical marketer? And I happened to want off of the team that I
was on at the time, and I was like, sure, I'll try
it. Right, it was a lateral move and it I think one of
the hardest, hardest things. And you can see based on this episode,
I am looking at the run time this is the hardest thing for me personally
is to say something in like three words right, to say to really like
get to the heart of like what gets to your heart, like really communicate
something that's going to resonate that you're going to remember. And that also is
true. I think like where that's where, Well, yeah, the bullshit
meter, the bullshit of God, I just said it, the bullshit meter
on I said it three times on our on my audience is like very high.
And I think that's one of the that's one of the palmarks of our
of our field is that we're we're skeptics and we do not we would love
to say that we do not want to be marketed to, and we can
smell marketing a mile away. And that's how that sort of education track and
developer advocacy track have like been such a foothold because it's it's not marketing,
but it is marketing, right, But I think like beyond that, really
it is important to we see ourselves as like we're selling a platform to people
who need it, Like our job is to find people who actually are a
good fit for our and actually just train the sales team on this last week.
It's like you're not trying to sell the product, Like you're not trying
to jam it down anyone's throat, right, You're trying to find the people
who are really excited about streaming to Lemontry. They're really excited about the the
real time data that they can get from our tool. They don't want to
wait for five minute polling, they don't want to refresh the page. That
experience is not enough for them. And so if we can find those people,
then our job is easy. Right. Then we just show them the
tool and we're like, let's let's get this set up in your environment and
let's get you going so that you can be successful at what you do.
And I think, like that's the dream, but really, if you want
to do that, you still have to figure out a short way to describe
what you do and why it matters. And that is one of the hardest.
It's one of like the shorter something has to be the harder it is
to make it good, and it's really very It's a challenge. It's a
huge challenge. So that's what has driven me into this field, is just
like the unexpected challenge of kind of marrying these two passions of mine being a
technologist and also being being a flabbermouth figuring out like where do I land with
that? And how can I connect with my audience with that? And it
is it is a great challenge for anyone who wants to do it. And
I will say, like you are a bit of a it's fun to be
like a bit of a unicorn. And I've I've experienced that. Like why
do you guys have me on this podcast? I don't know, Like but
because I'm in unicorn? Yeah right, yeah, because a lot of us
with technical backgrounds, our perception of marketing is, well, yeah, I
could wake up at eleven pound a few martinis and hit the golf course.
I could do marketing, sure, you know, And that's the that's the
perception of it, you know. Yeah, you're just just writing words on
the page. Right, Yeah, I saw mad man, I know what
you guys do you know? Having having I guess found a couple of companies.
Now, Uh, there is there is such a huge aspect here that
I feel like you're even under under selling Crosslin. It's uh, you've got,
you've got. Not only is it just too many words to fit in,
but sometimes you don't even have words at all, Like you first have
to come up with them to actually even say, like maybe you have a
feeling or an emotion you want to convey. Uh. There's just so many
different aspects there that have to end up not on not just on a marketing
page, but in a sales call and actually figuring out what that is.
It's a huge it's a huge struggle, for sure. It's not. And
that's not to say there aren't tons of marketers who are bad at their jobs
or doing a different job, which is like doing some sort of analysis on
big data to perform a b testuh, or looking at where traffic is coming
in through depending on your height in the funnel. You know, you can
do all those things. But that's not content marketing. That's reviewing some numbers,
which for sure is an easier job to do than what we've been talking
about here. I mean, I think there's a lot. There's a lot
to that. The marketing marketing is you point out, it's a pretty diverse
sort of skill set that and product marketing is really like being able to harness
all of that sort of engine in a way that will connect with your audience
in a way. I mean for B to B product marketing, it's like,
that's going to connect with your audience in a way that's authentic enough to
get you in the top of funnel gate, right and and then but and
but the other thing is you got you again. You've got to connect it
with what the product does. And I think this is where like I've worked
with I've worked with product marketers who don't have a technical background, and there
are plenty of them out there, and there's some wonderful ones out there,
But I've had arguments with people like that about like, well, you know,
I'm not going to say this because our product doesn't do that, Like
like, yeah, you can tell me that we have a security story.
This is one that comes up all the time, and this is not true.
If Kentick, we do have a security story. But a lot of
a lot of companies want to say that their product has a security story and
it just doesn't right, or they want to like and they want to tout
this thing that they heard that the product can do, and you're like,
where does that. It's like this sort of ball of energy gathers at a
B to B company about a technical product and what it can do in the
power of It's like this hype gathers up, and then as a as like
a product marketer coming from a technical perspective, you have to be like,
Okay, here's your ball. This is what's at the core of the ball,
and like I'm excited about the hype and I want to keep the ball
rolling, but we have to make sure that what's in there is solid,
that it's gonna be helpful to our customers, that and that, and then
because it's not, I'm so afraid of triggering that triggering that bullshit meter.
And it's definitely like, maybe that's why I'm I'm destined to be a middle
Uh yeah, I don't know. I'm not really a mental manager. I
kind of am. Yeah, So maybe that's why I'm destined to like I'm
never going to be in charge of the executive buyer messaging. I sort of
am, but I'm definitely like more, I am more afraid of lying,
Like I do not want to lie to people. I do not want to
get caught up on the hype train. And that was really hard for me
with our I AI product in particular, because I just I don't want to
get up caught up on that hype train, and I really want to mark
I don't really want to connect with the audience that is skeptical about AI,
and I really wanted our messaging to be like, you know, all all
other AI is like bullshit, I know, but this one you should really
take a look at it. You know. I want you to acknowledge that.
But hard to figure out how to do that in three words, you
know, I to just go with the same talk is like, you know,
all AI is bullshit, so as ours, but you know it's better,
yeah, I mean, but no, yeah, it's true. It's
like just the honest thing I think is really important, and it's really important
to me, and connecting two folks and letting them know that, like letting
them know that you've been in their shoes, I think, and it so
it really comes down to like empathy, right, I think empathy is a
huge part of it, just being able to communicate that and really authentically like
emanate that in your communications. And I think the companies that do that really
well that can can be very successful. So yeah, yeah, because in
cases like that, it's it's really not about the AI. It's what the
AI allows you to do that you care about. Yeah, yeah, that's
about what the humans can what the humans can do with it, and that
that story all always resonates really well. And I think that's why l l
M has particularly been so like why it just experienced such an incredible rise over
the last couple of years, because it really is fundamentally about like it's a
human, it's a it's a particularly human interface for a I think, yeah,
it's not all about empowering the human. Yeah for sure. All right,
good chat. I really enjoyed talking with you. Ready to break?
No, we still have to do PICKSI Warren putting you on the spot this
week, would you bring? Yeah? Well, you know I had something,
but then after the conversation started, I just I got a flash of
of what I should actually be my pick, And that's going to be The
Phoenix Project, which is a great book in the Dells space about a hypothetical
company that separates their ops team from their development team and they just struggle with
it in a lot of ways. In the company almost folds, And I
think there's a lot to do in the book with education and overcoming some of
those early challenges that we talked about in the podcast today. It's actually a
great book as well. So if you're anywhere in the development engineering space,
I can't imagine anyone on this call today wouldn't enjoy reading it. And you
may you may be like be able to put names and cry a little bit
on the inside when you see some of the problems that they they face.
But I highly recommend it for sure. You got to check that out.
Yeah, definitely a cool read, all right, Riislyn she brings a pick
this week. Yeah, I mean mine is definitely not as not as linear.
I can just talk about the book I'm reading right now, which is
really interesting to me. Okay, So it's my partner always calls me a
corporate fee up. And I told you that. I told you that I
briefly worked in more of like a directed developer B to B company and that
the enterprise sales model is a bit more my jam. I sort of discovered
that in my career and so I decided that I should learn more about corporate
stuff and understand like how it came to be. So I'm reading this book
The Corporation That Changed the World, and it's about the East India Company,
and it's really interesting because if you think about the like the VOC and the
East India Company, which were some of the world's first corporations, you probably
know that they went around the world and wreaked complete havoc on people and ecosystems
and exhibited such such stark corruption and violence that it's almost I mean, it's
just breathtaking to kind of think about that and read about that, and and
that's something that we're dealing with now, I think in our society is how
to how to move forward through that being able to acknowledge it. But it's
really interesting to learn about how it. It's like the way that corporations operate
today and what how you know, we talk about how corporation is like has
the same race as an individual. How did that come to me? And
what's the history there? So I'm kind of history Nerd and that's what I'm
reading now, and I would have It's dense, but it's not super long,
so I highly recommend it. So they're like the root of all evil.
Yeah, yeah, like let's let's stare it in the face if we
want to if we want to move forward to a new economic model as a
society, which that's another episode too, but definitely need to know like how
does the one that we have now? Like where did we go wrong?
I think it's really important to understand. Yeah, that's cool. I'd heard
of that book, but I didn't realize it was about the East India Trading
Company. I'll have to check that out because that sounds pretty cool. What's
your pick? So my pick is straight from the nerd archives. It's the
k nine S tool for managing or not really for managing, uh, it's
for visualizing your Kubernetes clusters, you know, instead of typing out you know,
sixty four word Kubernetes commands. kNs is just a CLI tool knin Scli
dot io that let you poke around and look at all the stuff that's going
on and Kubernetes quickly and easily. And the thing that I like most about
it is. It has VIM style bindings, so you can just use like
the J and K keys to arrow up and arrow down and different things like
that, and hit L for logs. And my favorite feature is when you
go to the log view mode, it's tailing the logs, but you can
hit the letter M and it just draws a straight line across the last log
so that when new logs come in, you can scroll back up to see
where you made the line and then just see the logs that have shown up
since you last looked at it. And so there's actually there's a lot of
tools in this category, but knis is definitely my favorite. So that's my
pick for the week. I was worried you were going to say there was
like some sort of AI interface not yet right, it's coming. No,
that would be perfect, you know, little AI interface where I can just
type WTF and it says, well, actually, yeah, right, yeah,
there is nothing going on right now? You know these plots in this
space which are the issue that you want to take a look at, Because
that's where my line of questioning always starts. That is the best AI entry
point? What is the best I'm going to suggest that I'm going to take
that back to our product. Yes, got to be able to respond to
that one. Yeah, Yeah, because literally I can't formulate a more accurate
question right at the moment. Nope. Awesome. Well, Roselynd, thank
you so much for being on a show. This has been a blast.
Yeah. Really enjoyed the conversation and really appreciate you having me and yeah,
looking forward to continue to listen and see what you get up to talking about
next. Yeah, for sure. And if you want to come back on,
And because we picked up a couple of different tangents there to go off
on, if you ever want to come back on and go down those paths,
I'd love to have you back on the show. Oh yeah, that'd
be awesome. Okay, I'm gonna, I'm gonna. I'm gonna take you
up on that, all right. Cool. And for everyone listening, whether
you're listening to the recorded podcast or if you're catching one of the live streaming
episodes on LinkedIn, YouTube, Twitch, or x A KA Twitter, thank
you for listening.