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.