What does it mean to be a network engineer in 2023—with Brian Davenport

Quick history lesson. The carburetor was first invented almost two hundred years ago in eighteen twenty six. And that was the main technology used in cars all the way until the late nineteen eighties or early nineteen nineties or so. So not that long ago.

That means mechanics, car mechanics, had to know how to install carburetors, fix them, tweak them, really just understand how they work and interact with the rest of the engine. It was an extremely important skill for any decent mechanic.

Now carburetors were great at the time. They met a need in automotive technology.

That was how air and fuel was mixed together and then delivered into the car cylinders. So your car wasn't going anywhere without a properly functioning carburetor.

But in the late nineteen fifties or so, electronic fuel injection was developed and it solved a specific problem for the automotive industry.

Basically, how can we get more power and better fuel efficiency from an engine without making the engine bigger and bigger and bigger.

You see a carburetor mixes air and fuel and then delivers it to the cylinders mechanically. That's the key there. You could tweak it a little bit, but because it's mechanical, it's imprecise. So it struggles with things like changing air temperatures, subtle differences in fuel quality, and it really limits how much output and efficiency that you can get from your car that has limited space for that actual engine.

Now fuel injection uses an electronically controlled system to really fine tune that air to fuel mixture and then delivers it much much more precisely into the car cylinders. And then that in turn dramatically improves performance and fuel economy. So what you get is with the same size engine, you get a better performing car that uses less fuel.

So here's my question for you. Those mechanics that new carburetors inside and out, they were subject matter experts. Was it unfair or maybe part of just the automotive hype of the time that they needed to update their skills to work on fuel injected cars?

No, of course not.

They still needed that foundational knowledge of how cars work but new and better technology came out and mechanics needed to learn it. That meant needing to learn how fuel injection works as a system. But also how to use the tools to diagnose and fix those systems.

In the same way, the network industry has seen these sort of bursts of change every so often when a new technology comes out, that solves a real problem, and then it starts to get adopted everywhere.

And and in the same way, engineers need to learn that new technology, but also learn how to use those tools that you use to work with it. So where are we today? In terms of skills, foundational knowledge, and the tools someone uses, what does it mean to be a network engineer in two thousand twenty three? So in this multi part series, I'll be talking to experienced veteran network engineers about what they think It means to be a network engineer in twenty twenty three. You're listening to telemetry now. Let's get started.

Alright. So with me today is Brian Davenport, who's a solutions engineer for Kentech solution. Is it sales or solutions engineer?

Depends on the day, the the day of the week, I guess. But, yeah, either or.

Okay. Either or. I always liked saying solutions engineer because I didn't want to associate myself with the sales team.

Yeah. Yeah. Yeah. Yeah. There's that.

Okay. So Brian is a solutions engineer. Brian, we've both been engineers in one way, shape, or form for a very long time. And we've both been into the weeds of networking in general.

I guess you could say right. And, I I think we both have enough actual time of years of experience under our belts to be able to see that things are changing for network engineers out there in the field turning wrenches. So first of all, Do you agree with that or no? And like my math teacher in seventh grade said, explain your answer.

Yeah. The speaking of math teacher, classically trained. I'm actually a high school history teacher. Sort of graduated college with.

And then I kinda, yeah, and then I kinda transitioned into into, technology, but, you know, I I I know you've been a sales engineer as well, and it is to me very similar to to teaching in a sense of, you know, if you're high school, and you're specializing in history, you know, I'm enterprise and specializing in network. But you're still teaching, you know, something to an audience, for sure.

Yeah. Yeah. So did you spend time in the classroom?

I did. Yeah. So I did. So, I was, you know, eighteen and you have this, like, you gotta figure out what you wanna do with your entire life.

You're eighteen. Now what do you wanna do? And so I was like, oh, I guess I wanna be a teacher. I'll try that.

So I went to college and I did enjoy. I've I've always kinda liked that. You know, aspect of of working with people and helping them learn stuff. So, you know, I thought it was gonna be a good career choice. It wasn't exactly what I wanted to do. And then luckily I kinda found, for me, a very, fulfilling career in in kinda keeping some of the teaching aspects that I that I studied in school by working with technology, which I've always been, you know, kind of a computer nerd at heart.

And how I got to where I am.

Yeah. Very interesting. I didn't know that about you.

I was actually a high school English teacher for five years. In private schools. Yeah. Yeah.

Prior to getting into tech. And my reasons for getting into tech were very practical because I loved teaching and I still do. And I I agree with you. I agree with you.

I I was a solutions architect. That's what we called it, for a few years for a very large bar. And still got to be a nerd. I had to be an engineer through and through.

I was on the command line. I was working with customers, on on the command line, and doing, designs and and and had to, as a requirement of my job, had to have a deep understanding of the latest technology of how things integrated together, what what problems we really did solve, how to add a lot of margin to projects. There's that.

But also to have the soft skills to be able to deliver compelling presentations to interact with customers over. I loved it. I love that. That was my favorite job. I I love what I do now. Don't get me wrong, but I really liked being a sales engineer solutions architect very much.

Going back to your original question, though.

I was about to say, are you stalling is the is my question, but what do you think? Do you agree with idea that engineering, network engineers, the nature of being a network engineer is changing?

I feel like it's changed a ton.

Right? If you go back to when I first started, like, you know, the cloud wasn't really a thing. You know, it was there, but it wasn't what it is today.

And it was a lot of like on prem networking to so much Cisco. Like, I just remember, like, you know, nine years ago was all about Cisco command line, you know, being a CISSP or CIDR can't remember the acronym names now. Cie or whatever, or Cisco architect. And then it's a lot of, like, you know, understanding routing, switching and, you know, spanning tree and all this kind of stuff. And then, you know, slowly you moved into what I kinda saw was a huge explosion in SD WAN. So all the engineers were kinda learning SD WAN and kinda how all that stuff worked. And then over the last two years.

I think it's changed a bunch, like, it's a ton of cloud. And, most engineers I'm working with now are writing Python code to do a lot of automation.

You're not really banging away on the command line like it used to be. So I think it's it's changed tremendously. Yeah.

Alright. So then let me ask you this. I I do wanna ask you about degrees and certifications and all of that, but you already touched on new skills that engineers pretty much need these days. What would you say are the the the latest skills that engineers need to acquire if they are brand new to the industry, or maybe veterans of the industry, but need to, adapt to how things are changing.

I think that understanding how packets move on a wire is kind of becoming a dying art in a sense. And I think that when you're troubleshooting things, being able to understand those concepts of, like, if this needs to get to this, What is it gonna do? Right? How is it gonna do that? I think those core concepts are are still important. Right? And I think that having that skill set is is great.

But with a lot of that being obstructed away through, you know, overlay networking and cloud networking.

The skills that I see, like, you know, a lot of the sharper engineers I'm with is really what I've I was so glad somebody encouraged me to do one of my mentors like six years ago.

He was like, if you're gonna be in this field, you have to know how to program. You just gotta know how to do it. Just pick up a programming language and learn it if you wanna be a great engineer.

So, you know, I'm not a c programmer or anything, but I can write some Python and and understand it. And aside from being able to code, I think what learning, some programming will teach you is, where, you know, traditional network engineering, you understand how the packets move on on the wire.

Nowadays, you know, we have a lot of application performance issues or latency issues. Learning to program kinda teaches you how, an application works. Right? So you can kinda get that other layer of thinking about something, even if you're not actually writing code all day.

It gives you another layer of understanding. So for me, I think most engineers I'm working with are picking up programming skills for sure. Like, I always am doing API work now when people are writing code and we're working together on it. Nothing crazy, you know, at all.

And then the other thing is the cloud is like I was just at AWS re invent and, you know, a lot of people that I talked to you weren't called network engineers anymore. Although after talking with them for five or six minutes, they were they were network engineers three years ago, but now they're cloud architect or, you know, you know, cloud network engineer or something like that, and they're kind of transitioning into these hybrid roles of understanding the cloud. So I think most engineers are probably getting pushed towards learning that. But if you're interested in in the networking or traditional networking field, I definitely focus on understanding at least how AWS Azure and and Google work because those seem to be the big the big players to have an understanding, and there's a lot to it.

Yeah. So for new skills, learn a programming language, and you mentioned Python, and learn how public cloud works.

Yeah. So my network needs.

There's a few main pillars there.

Yeah. Yeah.

If those are the two bullet takeaways and then don't lose the passion for under standing how TCP IP works and how BGP works and how routing protocols work because, you know, when something really breaks, I feel like the networking team is always the one that called in, you know, like it's or they the only ones that they get blamed, but I think part of that is because they wanna pull those guys into the problem because they actually how the data moves, right, and they can, you know, you always have that guy that just knows the, you know, where to look and how to fix something for sure.

Cause you have a broad skill set.

Well, I mean, that's something that we deal with it at at work and and in the industry as a whole right now is that most, not all, but most of the applications that we assume, personal and for work are delivered over the internet and the local network that you happen to be on that day, whether you own it or not.

And so you know, to me, it it makes sense that there's it's just logical that there's a tremendous amount of application, performance information embedded in the network. So, you know, a network engineer who understands network visibility, network devices, how how information works over a network, and isn't necessarily as interested in, like, application code reviews and server logs.

They have a unique a network centric perspective into application performance that is absolutely required today. It's not like a cool thing. We're like, we got this idea let's build a platform around it and try to sell it. No. This is how we consume applications today. So I feel like it's the illogical extension or or another aspect of APM that we really need to pay attention to and and unique for network engineers in particular.

Yeah. And I one thing I kinda didn't say, and it it's like I it's the whole COVID shift too, I think was a big transition for network engineers where, like, you know, I worked for a different company than Kentech prior to COVID. And, worked in networking, and it was a lot of, like, how do these remote offices connect together and site to site connections, and people are coming back to the data center, and connecting to an application. And now it's, you know, I see a lot of people are all spread out through the world and it's kinda either from the cloud in or from the data center in or, you know, what we're doing with with synthetics of just like, what's the internet weather? Like, is this even my problem? You know, if it's a network problem, is it my network? Kinda has been a big transition.

The internet weather I I've never heard that term. I really like it a lot. That's really cool. So you got a new network engineer or maybe somebody who's changing careers or what whatever.

Somebody's getting into the field and they wanna become a great network engineer, but today. Right? You mentioned that they need to have a basic understanding of the fundamentals of networking, how packets move over a wire. Okay.

You mentioned that they should probably learn how to program in in a modern, relevant language like Python, they should learn public cloud.

What do you think about the whole degree versus certification thing? That was a that was a debate that went on well, no. It went, like, it was on and off for, like, ten years of my career where people were, like, anti degree pro certification, pro degree anti certification. In fact, there was a whole there was a whole segment of network engineers that were against certifications altogether. Where where do you think that is today?

So I have probably bias, because I don't have any certifications.

So you know, all certifications are a waste of time. Why would you want them? But There you go. I don't.

I want your gut real honest answer.

So here's my thing with that. Right? So I think it is, and I hate to fence it on anything, but I really do think, there's a couple things I wanna, I wanna dial in to, on that topic. And and one of the key things I think you you you said, but I'll I'll get back to it. So if it helps you to learn e technology, and you're interested in it, I always found that studying for something and kind of really pushing to under stand, it does help you do that. Right? It helps me anyway.

So I do think there is value in that.

The problem that I always find with some search is it feels marketing, exercise y to me sometimes. Like, I've gone through, like, I I do have a couple certifications that I've gotten. And, you know, it's very a lot of the ones I've gotten are like vendor specific where it's like you're kinda getting molded into this architecture.

I feel like personally my gut is they were really important a while ago and they're not as important now, but I don't know that to be true. That's just my gut feeling.

I do wanna ask you though. You you kinda said something that struck a chord with me, which is like, say you're changing careers, right, or you wanna, you know, move to be a network engineer within an organization or maybe you wanna be a security engineer or something like that.

That feels hard.

Like, it feels like a hard process, and I'm curious like why you think I have some thoughts on why that is, but like Why do you think that is, to to or do you think it is to move to a completely different new role within an organization and and, If yes, why? And if no? Like, why?

So is it is it difficult?

I mean, it depends on the role. Right? It depends on how adjacent that new role, that new niche of networking or or technology is to what you're currently doing. So for me, going from traditional network engineering to network visibility and now network observability in a technical marketing role, not very hard.

Because I'm using the, well, I'm discussing the same technologies I've always been using. So not not too difficult, but to go to something a little bit more different, divergent, like, network security.

Yeah. Yeah. I gotta learn both the jargon, the mindset, and that takes time. So it took me probably two years to almost maybe three years of working in purely network visibility and observability to to be at the point where I now can literally just for an hour, go through an entire conversation deeply about the mechanics of network observability, the problem solution and all that stuff. It took a few years. I I have to imagine that it would take a similar amount of time getting into network security. However, adding on all the stuff that I don't know.

So there's that. I don't know. Maybe that's not a good example because, you know, network security is built on networking. So, alright, what's that?

But I think too, like, I don't and and I'll kind of convey One thing is that certifications and and education is is definitely important, but I think for me personally in my career, the most important is having a good mentor of finding, you know, somebody within the organization that's been there before Like, you just learn so much more, from that.

And, like, you know, if you're, you know, at a company and you're interested in moving positions or something like that, finding, you know, some kind of relationship or somebody that, you know, can can help you kinda learn the ropes a little bit in in mentorship mentorship in in technology. I think in probably any super important, but it's another thing I would I would throw out.

Yeah. I'm sure. But going back to this original question of you know, how how what does networking or network engineering look like now in twenty twenty three? And what does it mean to be a network engineer?

In my introduction, I talked about the, the the car mechanics of years ago that were subject matter experts on carburetors, right?

And they were experts on it because that was a technology at the time. And then in the late nineteen fifties, electronic fuel injection was invented. And then by the eighties or nineties, that all most cars were fuel injection. And I made the comment in the introduction, you know, was it was it unfair to those mechanics that they had to learn a new skill?

Was it was it Was it just automotive automotive industry hype and that they were battling down to? And they they they needed to be stalwarts of traditional automotive mechanics? Well, no. It's that's a kind of a ridiculous thing to think.

The technology changed, and and so be the nature of being a mechanic change. And that that's really how I look at networking right now. I mean, the the technology changes as a result of the needs of the industry, of the needs of people that are consuming the services we provide. And and therefore, engineers change along with it.

I mean, that's just the nature of, of anything. It's kinda, it's kinda weird. You know, when I hear like a disdain for folks that are network engineers, but really trying to learn the latest technology or like network automation, and they'll like they'll like use derogatory to not not necessarily derogatory. It's kind of funny, but they'll say like, oh, you're just a hipster network engineer.

But you can sense a little bit of bitterness in there. It's like, hold on a second. Like, this is what we're doing now. It's not like would you say that to a mechanic in nineteen sixty eight who, you know, has a fuel injector car in in a shop and and you say, oh, I'm not gonna work on that.

I refuse, you know, that's beneath me. That's ridiculous. So I really look at it the same way that the the industry is changing for whatever reasons, and in whatever ways, and engineers have to adapt as a result. That's just what it is.

So I can so when I was learning to code, I think this will be parallel to that. So I learned like Python. Right? And then I had a friend who was a developer.

And I was like, what's the what's the new languages? And he was kinda like newer age. Right? And he was like, oh, you have to learn React.

It's this front end web web framework that's like super popular, for building single page applications, and you gotta learn this. Right? So I bought some u udemy courses and was learning React. Right?

And then, one of the developers at the company I worked for, he was a he was our web developer. Right? And I was like, Hey, I'm learning, like, React. Here's what you think about it, and he was like, well, you know, how JavaScript works?

And I was like, no. And so it's kind of that like and I think we kinda even said this at the beginning of, like, understanding how packets move on the wire. Yeah. And some of the perils you can fall into when learning new technologies is, you know, once he kind of said that to me, then I was like, no, and then I went and learned JavaScript first, and then transitioned into trying to figure out how react work.

It just made it so much easier. Right? Cause you knew this is like, okay, React is a framework built on JavaScript, much like, you know, some network automation thing. If you're, like, really, really good at it, but you know, that you don't understand underlying networking concepts, I think you can get into, you can get into trouble there, especially when things break.

But, you know, there is definitely a resistance to to change, and I think it's you know, the people who are web developers probably have that. Like, there's a new web framework every three weeks to choose from and in our space, there's some new technology movement that's always happening. So if you're gonna commit time to it and learn it, and then it goes away. And, you know, you wasted all this time, you know, I can see, having that frustration, you know, of of being like, can't we just all?

Can't we just go back to the old days of I get it.

But, you know, moral of the story, I think, is foundational knowledge is super important. And, you know, the guy who learned to build a car and was a car mechanic and then didn't resist new technologies, and learned them as they came is probably a really, really good mechanic compared to somebody who resisted the change.

Yeah. Absolutely. And and I use that example of being a car mechanic, and you can continue it with it, you know, and and the, advent of, various type of computer technology in cars beyond just electronic fuel ignition, rather injection.

And and how today, you know, my mechanic right down the road, it uses an entire suite of computer diagnostic devices to figure out what's wrong with the car. And often to even fix the car.

So when, when you say requiring those foundational skills or that foundational knowledge of networking still important.

What specifically are you talking about? You you talked about how a packet works on a wire. That's that's fine. I understand what you mean by that. But can you expand on that a little bit?

Yeah. So I think the exercise, the the best way to to kind of think about this exercise is I think I call it a packet walk. It might be called a packet walk. I'm not sure.

But if you just are sitting at your computer and you pull up a website, Google dot com and you press enter on your browser, can you think about every single thing that happens between the time you hit enter and the time the page renders? What is that? What's actually happening, from a to b, right? And, like, you know, so doing, you know, ARP or doing the TCP connection or doing the DNS resolution or doing the get request or, you know, kind of following or or like how that packet is switching across different routers and leaving your PCs Nick and kinda if you can understand that concept, I think that's what I mean by understanding, like, the core fundamentals of of of how data moves.

And it's also what will once you start learning those concepts, if you're new to networking and interest it in it. That's when you all just know that we live in the matrix because when you are then in California at a trade show talking to your wife on FaceTime who is in main, and there's no wires, and it's all in real time, and you can see each other. You realize that none of it's possible, and we live in a simulation, and it just doesn't make sense. So, like, understanding those core concepts and building on them will really start to blow your mind when you when you when you understand how everything's connected.

So That's what I like about. You know, tech is, you know, we mentioned it's constantly shifting, but I always like where you never know. Like, the more you learn, the less you understand, it's like really weird profession that way. Or the more layers you learn, the less you, like, how does this even work, which is pretty cool.

Yeah. In fact, in that packet walk that you just mentioned, you can dig into any one of those components and and really gonna be. Well, you talked about ARP. You talked about DNS resolution.

We can spend the next month talking about just DNS and and how that works, how it's used for load balancing, how it's used for, just, you know, obviously for name resolution. It's that's basic function, things like that. So there is a lot there. And and I I think that that's where we are as network engineers, today two two thousand twenty three. Is that we are required to have a a broader understanding of not just how a packet goes from router a to router b and how a BGP adjacency is formed still important.

But because of the nature of how applications are consumed, we really need to understand that broader spectrum of of what's going on with application delivery. It's just part and parcel because it is over a network now. We have no choice.

So Yeah.

For sure.

The nice thing with this computer age is you know, going back to the education thing, you know, nowadays you really have everything there. You know, it's some almost too much information sometimes, but resources I really like, like, this podcast is not sponsored by Udemy.

But, Udemy, I've I've, like, found as a tremendous resource because it's you know, those are courses that are typically created by people that are doing the job and you can find some good creators in there to learn the skill sets that they find important and I've learned a lot from, Udemy specifically. I think Coursera is another one. Yeah. But other than that, just being able to Google well, is a skill in and of itself. I really do.

Being able to Google well. Find the information.

I think it is. I mean. Yeah. Fine.

More like know what question to ask is a better way to say that.

And that's where I was about to go with it because you do need some, element of foundational knowledge to know what question is to ask in the first place. You know, if you have if you're a blank slate, you don't even know where to start. So you do need that foundational knowledge, and then you can build upon that. So then so then tell me what you think are the less technical skills that somebody going into networking really needs to think about acquiring today. May I don't wanna say soft skills because those are you know, but more non technical.

Well, what I kinda wanna say is, like, you, you have, like, all of these products or solutions likely that your company owns. Right?

And I think that a lot of times I find people might spend time with ten percent of the product, right, or ten percent of this thing that they they have. And I think I saw a soft I don't know if it's a soft scale per se, but just having the wherewithal or the passion or whatever it is to really be an expert in the field that you're in, like, be passionate about it. You know, it's it's hard. You know, tech burnout is definitely a a thing, but I think the people that excel in it are are super interested in in learning more and and being passionate about the tech they're in.

Kinda not the exact answer I wanted to give, but I hope the concept of, like, I think a soft skill to succeed here is is having, an actual interest in in the technology and and being passionate about learning more about it and sharing ideas Like, I always find those are the best engineers to work with for people that are super excited about what they're doing.

And that's why I asked it that way. I didn't want you to say, oh, you need people skills, you know, the typical soft skills. I was looking for what do you think it takes beyond just knowing how to configure a thing, you know, or how what TCP flag is, what TCP flag? What do you think it takes nontechnical to be a good engineer?

And and again, we're now getting into the the typical you know, the trope of people skills and empathy and stuff, which I I say trope, like, you know, negatively. You do need those things, but I think it is more than that. And now now as far as passion, though, I I was never really passionate about networking until I started getting eyeball deep into it. Does that make sense?

I mean, at the end of the day, a job's a job. Right?

But I think the passion of, so what I was gonna say is, like, I think a better answer to your question of like soft skills may be to, understand a problem before building a solution.

That is a soft skill that I took me a while to develop, where, you know, you'd have something you're trying to solve or maybe a cost or asks for something or your boss asks for something and you think you understand it and you build this entire solution and then you go back and then you get yeah, this is kinda cool, but that's not, you know, really what we were trying to do. Right? And you kinda go through these processes of wasting time. And the other thing is ego loss. I think is big. There's a lot of ego.

Sometimes in tech of being right or wanting to be right and I think that being okay with being wrong, and being okay with embracing new ideas and understanding why somebody is proposing a different technology or whatever, are some soft skills that are key.

There.

Passion, I think, is for any any job you're doing for longevity.

You gotta have some interest in it if you can, you know, like, say in tech, I think it's important.

But Yeah. That makes sense.

At the end of the day.

Right.

For me, the passion wasn't necessarily for networking itself as a field, but for figuring stuff out and fixing it, that I really enjoyed. Now it happened to be networking. So, of course, I developed a great, great interest in networking, and that's fine. They they were in parallel.

No problem. I gotta say sometimes I'm in my basement, and I'm figuring out why, you know, there's a plumbing problem. And I figure out some kind of weird solution, and I, you know, watch some YouTube videos of what plumbers do. And then I fix it and then that's my Saturday.

And, man, when I'm done, I'm like, well, that was really fun. That was cool. I hated it at the same time because I had a problem with my plumbing, but it was really interesting. Or when my riding mower didn't work properly last summer, and I spent half a day trying to fix it and I figured it out.

I figured it out. I watched the YouTube videos and figured it out. So I get a similar fulfillment from networking, again, because developed that skill, and so you're in there trying to figure out a problem for a customer or design a solution, and then you make it work. And it's very fulfilling.

So I think that's where I would agree with you as far as the passion side is being, doing something meaningful, doing something productive, and it does happen to be networking, which works great. I love it. So, they they go hand in hand for me.

Yeah. Totally. And I think it's the, you know, the next time that problem next time that lawnmower breaks or next time there's a network problem or next time there's a thing and you've gone through this process of solving it and and then you can do it quicker the next time and quicker the next time you start to master. I think there's fulfillment in that as well, you know, the more times.

You solve the puzzle. It becomes easier. And there's always new puzzles. To solve.

And, and then you watch one twenty minute video and you're a subject matter expert. That was most of my career. I got a customer meeting coming up. Quick twenty minute video on YouTube.

Me too. Walk in. Like, I'm, you know, SME of the year. So it's pretty.

Oh, yeah. That works.

Yeah. That's the humbling thing too. It's like you said when you you think you understand DNS, then you talk to somebody who understands DNS. Right?

You think you understand CPIP and, like, you put it on your resume and then you have some guy that's like, oh, you understand TC TCPIP. Okay. Let's go. You know, so there's, like, know, you're gonna gotta be careful with with what you think you know.

But understanding, I think that, you know, having that humbling of knowing you don't know everything is is is critical.

Yeah. Yeah. I'm probably more critical now than ever. I mean, two thousand twenty three and beyond, with the the overlays with, networks that we don't own, like public cloud, containerized architectures with, with the the the diversity of technology that is involved with delivering an application to somebody sitting on their phone or at their computer, and you're right in the middle of it as a network engineer.

That just it it's just too much to understand all of it at once and it requires some level of humility for sure.

And I I never really bought into this idea of mean time to innocence. I don't care for that term. I don't I don't really use it because I back when I was a field engineer, we didn't use Zoom. We were using Webex.

We were getting on the call to fix some problem. There would be a server administrator, a maybe the patient person, security person, network person, whatever. And we were all working together to figure out what was going on. It wasn't that, look look at that quote, it's not the network, and then I dropped from the call.

That never happened. It was granted I I did wanna, find a solution. And if it wasn't the network, maybe I kinda, you know, faded into the background of the call, but we were all working as a team to figure out why this application wasn't working right, how we got the security breach, whatever it was. I don't care for the meantime to innocence idea, the that that philosophy.

And and I think it's even less so today because you you can't know everything at a subject matter expert level in the in the entire workflow of delivering an application.

And and so, you know, you have to rely on others in order to, you know, to be part of that team in order to make sure that that end user's end user's experience using your application is is really good. And figure out, you know, why there's a security breach, why the application is slow or or whatever it is. So I think I think that's now more than ever. Again, it's it's a human thing. Not necessarily a network engineer skill. Right? Just having humility is probably important in any field if you think about it.

Yeah. Yeah. It's a whole another podcast to talk about silos and why silos exist and kind of that kind of thing within organizations, maybe for another time. But I do agree teamwork is makes the dream work.

Brian, it's been it's been a great conversation. I really appreciate you coming on. I'd love to have another talk with you coming up, this spring. This when whenever you have some availability, we touched on so many top today that I think we could grab one of those threads and really, really run with it.

Yeah. No. This is great. I I've enjoyed listening. And if any of you guys are first time listeners, I'll I'll probably post this on LinkedIn.

So you found it this way, definitely go back and listen to the rest of what Phil's done. I love I love the short form of this podcast and It's been a bunch of really interesting conversations, with our founder and some machine learning stuff. So I encourage you guys to to to listen to them all. You can consume them quickly.

Cool. Thanks. So if anybody wants to reach out, Brian, how can they do that online?

Yeah. Please if you are listening to this, connect with me on LinkedIn.

You know, just Brian downport on LinkedIn, you'll see a picture of me.

That's typically the best way to to get a hold of me, and I I love to see who the people are that, you know, I'm working with and what you've done. So find me on LinkedIn.

Awesome. Thank you. And, you can find me on Twitter at network under Phil. You can also search me on LinkedIn.

Just search my name, Philip Jervasi, Philip with two l's. My blog is network fill dot com. Not super active there, but you can find some contact information. Now if you're interested in being a guest on telemetry now or if you have an idea for a topic, please reach out to telemetry now at kentic dot com.

We'd love to hear from you. Until next time. Thanks. Bye bye.