Speaker 1: 0:01

Hey folks, back in October 2024, I had the pleasure of participating in USNUA's first podcast panel, where Drew Conroy-Murray, ned Belovance, william Collins and I discussed the current state of the network engineering profession and what it takes to create and sustain a successful career in our ever-evolving field. The fine folks at USNUA have allowed the art of network engineering to share the show with you on our platform and I think you'll enjoy the dynamic conversation that follows, thank you. They host networking user groups, or NUGS, all over the country, where free food, free beer and free information is presented in a relaxed atmosphere. For more information on the USNUA, as well as access to a variety of member-only educational resources, head over to usnuacom and check out the membership section to become a member of this fantastic group of network engineering professionals today. Now sit back. Enjoy our PA Nugs podcast panel from October 2024. As always, thanks for listening.

Speaker 2: 1:16

I think I mentioned when we started this thing. This is the first time we're doing something like this. It's a joint initiative between some different people from the community and the USNUA to really bring together what we're referring to as the podcast panel, right? Just basically people that are involved in the community, people who are in the know and people who have a pulse on the industry, and what we're trying to do is really get their perspective, you know, essentially put a face to the voices that everybody's listening to on these podcasts. Right, and I'll let everybody back here behind me give an introduction for themselves. So I don't butcher it from my side of things. But the one thing I did want to mention as we get into this is if you ask a question, I'm probably going to repeat it. They mic'd me up for some reason so that way they can record everything. I don't know podcasters, weird people. I also have a second mic. If you have a comment, chances are I'm going to pass you a mic. So if there's a comment, feel free to, like you know, wave your hand, throw something at me, whatever's easiest, and if it's a question, I'll probably just repeat it so that way they can respond to it.

Speaker 2: 2:14

I passed around a couple of question sheets. I guess we'll call them. If there's something on there you really want to talk about, you know, feel free to acknowledge it. Right, you know, we'll get there in some way, shape or form. I'm probably going to start with changing landscape and we'll go from there, but we'll dive in. But, eric, if you want to go to the next one for me, there we go. I'm going to go left to right, although the pictures don't line up that way, and I'm going to let everybody introduce themselves here real quick and we'll dive in big enterprise.

Speaker 3: 2:52

Started out, my first job was actually managing CSS, load balancers, certificates, which was like the worst job ever. I would have rather worked fast food at the time, but you know I put in the time. So I started in the data center and then pivoted to cloud. When cloud started really becoming a thing, did the multi-cloud thing, solved a lot of problems in the enterprise. And then now I work for a startup for three years my first time working for a vendor and then I started the cloud gambit podcast and I co-host with Yvonne Sharp and really what we do is we focus on a lot of the adjacent areas to network engineering. So my core was network engineering.

Speaker 3: 3:30

But one of the cheat codes I had when I was in enterprise I'm curious, I like talking to people. So that was how I was able to get things over the finish line in the enterprise. Hey, I'm gonna go to talk to security, I'm gonna talk to the developers, and it's some of those points like we couldn't work from home. This is a while back. And so, hey, they're in the office. I just go over and talk to them. You know they're right there. So I figured, hey, why not do that with some of these engaging conversations. So we talked to everybody from, like network engineers, founders of startups, venture capitalists, because it all, like, really is closely meshed together, so happy to be here.

Speaker 1: 4:07

Hey guys, andy Laptev, co-founder, co-host, art of Network Engineering. I started out in tech working at a Verizon Central office pulling wires for POTS lines and DSLs and getting the bejesus shocked out of me when you would touch the actual things. Cable guy Comcast for five years worked my way into their NOC with a CCNA and I got a job in fintech for six years managing their global WANs. Burnout there and right toward the end of my burnout got plucked at Juniper to do some product management stuff, some customer experience work and what else can I tell you? Our show, I guess, because this is a podcast panel, we wanted to tell the stories of network engineers doing the job. So people like you, the operators we didn't really think that audience was all that well served at the time. So you know what's it like working in an Ock, what's it like climbing that ladder, what's it like being a network engineer, and it's been awesome.

Speaker 1: 5:04

I've gotten to meet a ton of people. I mean we were just at Cisco Live. I went to my first Cisco Live. I couldn't walk 20 feet without somebody being like oh my God, are you the guy from the thing? I'm like whoa. So it's just been beyond my wildest dreams. Started in COVID. It wasn't like a plan, we were just home, we were studying for start a podcast. These conversations in our study group are kind of funny and it just kind of took off. But great to be here. Thanks everybody for coming. Thanks Andy.

Speaker 5: 5:28

Hi, I'm Ned Belovance and let's see, we're doing history here. So it all started on a warm summer day in 1970. No, so I got my start in tech on Helpdesk as I think a lot of people might and worked my way up through there to be a desktop engineer. And then I started getting into networking, took my CCNA, tried to go for my CCNP, failed the first time, said forget this stuff, I'm going to learn VMware, and never looked back. So became a systems administrator and then a consultant, and I worked in consulting for eight years and while I was doing that, cloud happened. So I had to start learning AWS and Azure, because that's what our clients wanted us to set stuff up on. And hey, networking is there. So now I have to remember all the stuff I learned in CCNA and also then augment that with additional things that were unique or somewhat unique to the cloud. So that's what I was doing for eight years, and then I decided to get out of the consulting biz because that is a lot of stress Stress, I think, is the right word I'm looking for and so I went into full-time content creation and being a technical educator. So I have a bunch of courses on Pluralsight around things like Terraform, vault, azure, and I also teach live stuff.

Speaker 5: 6:52

And, oh, I have a podcast because this is the podcast panel. I have two podcasts because one is never enough. Oh God, they're like Fritos. So, seriously, I'm on like my sixth podcast at this point. So one is called Day Two DevOps. That is on the Packet Pushers Network that I host with Kyler Middleton. She's awesome. We talk about anything loosely related to DevOps. So that could be career advancement, it could be a new tool, could be just someone who's got a cool thing they're doing at work and they want to talk about it.

Speaker 5: 7:24

And I also host a podcast called Chaos Lever with my buddy, chris, where we talk about the history of technology. So we recently did a podcast. We recently covered that whole WordPress thing that's happening. I don't know how many people are aware of the nonsense that's happening with WordPress. I don't really care about that, but it gave me a chance to talk about BBSs and blogging and how all of that morphed into the fact that WordPress runs like 50% of websites now. So if you like tech history a little bit, should I give them a little preview? Go for it.

Speaker 5: 7:56

I already forgot what I'm working on for next week. That's terrible. I spent all day writing no, I'm kidding, excel is turning 40. Microsoft Excel is turning 40. Microsoft Excel is turning 40. And it also runs like 70% of finance in the world. So I thought it'd be fun to look back at spreadsheets a little bit. Also, like 90% of automation, most networking is really just configured through a spreadsheet. So I thought it'd be interesting to look back at the past of spreadsheets where they came from and how they evolved.

Speaker 6: 8:27

And that's me. I'm Drew Connery Murray. I am kind of the odd person out here. I came into this industry on the reporting side, so I've been covering the tech industry as a reporter, writer, editor, blogger, podcaster for almost 30 years now 20, 25 years now. I've worked for outfits like Network Magazine, network Computing Information Week. For a while, when the Interop conference was running, I was the director. I was responsible for bringing in all the technical presentations that happened at Interop.

Speaker 6: 9:09

Through my role as an editor at one of the magazines I was working for, I got to know Ethan Banks and Greg Farrow, who founded the Packet Pushers Network. Greg invited me to start a podcast with him called Network Break, which is like a weekly IT news show. We started it. We were having a good time. Then I got laid off from Interop. So I went to Greg and was like if you want to find another co-host, you know somebody connected in the industry, that's fine. He's like do you want a job? I was like, well, yeah, I need a job. That's how I joined Packet Pushers.

Speaker 6: 9:34

I've been there many years now and I co-host three podcasts Network Break. I co-host Heavy Networking, which is sort of the flagship networking podcast, and a recent podcast that I started with Jennifer Minella called Packet Protector, which sits at the intersection of networking and security. Ned is on the Packet Pushers Network and Scott Rabban has Total Network Operations. We just launched a new podcast called Technically Leadership. If you're looking to get into technical leadership, that's a great show and we've got some real niche ones like IPv6 Buzz If you're trying to get your hands around IPv6, some really deep content there.

Speaker 2: 10:09

Given your perspectives right and the history that all of you mentioned here during the introductions, the landscape in network engineering today right. Maybe we just start there Perspective of where you've seen it come from, where it's going and what you think the next generations are going to look like. For today's network engineers, what they need to know, where the industry's heading.

Speaker 3: 10:29

Yes, I remember when I first started doing any sort of automation it was a long time ago Bash, perl, expect, back to the hating CSS load balancers that was what I was using to solve that problem. I wanted to automate it and it freed up a lot of time. It allowed me to work on other things and back then it was a combination of some different scripts and we basically had a jump server and in that jump server we gave the developers the ability to fill in a certain spreadsheet. They would put it in a directory and then I had a cron job run at strategic times during pre-approved change windows that would go out and do things. When you look at that and you look at, okay, it's Linux, it's a cron job, you're gluing things together. And then I look at recently, these cloud pipelines I've built. It's so eerily similar because it's okay, I'm still using Linux, I'm still gluing things together, I still have this, this instead of a long-lived server. It's ephemeral, like it's coming up during the pipeline and it's getting everything staged and then it's, you know, tearing back down. But there's so many similarities there and just thinking about how much time has passed and looking at okay, that was then. Okay, it was pearl and bash, but now, okay, it's still bash, and maybe it's Terraform and Python, or Terraform and Golang, and you know a YAML file that sits in a Git repo. It's very similar.

Speaker 3: 11:51

So, yeah, things have changed. And I think the thing that really has changed is you have networking under the hood everywhere. So even if you look at you know you have physical, you go up to layer three and layer four and then you go up to the application networking. But even as you layer on more abstractions, under the hood it's a lot of tunnels, a lot of reverse proxies and a lot of things. But the thing that's actually changed and one thing that I find a lot of network engineers are, I don't want to say, scared of, but they just want to stay away from it is the tools that we use to interact with these things.

Speaker 3: 12:26

So, instead of going in and hammering on various CLIs, the workflows change. The way that we interact with these things has changed and architecture's changed too. So with the more abstraction like the other day, I helped someone that. So it was a Kubernetes cluster in AWS add an EKS cluster and they made a change to some Terraform. I think they changed the version or something and that actually tore the cluster completely down and brought it back up. They caused an outage, like the immutable aspect of this. But there's a lot of things you can do that will actually make configuration changes to that cluster in place, like maybe a node group or tags or things like that, where you're not gonna cause an outage. So really in the architecture world in the cloud, it's a lot of reading, it's it is kind of dry, but you just have to know how these resources work and what their behavior is you embraced automation way before me, or anybody else I know did so.

Speaker 1: 13:22

I got my CCNANA in 2012, I think, and there was no automation on the exam. There was none being taught. I got a job at a NOC there was no automation at all, and five of six and a half years at the FinTech role there was no automation. To speak of what's changed, like to answer your question what's changed? Automation and cloud were the two big 800 pound gorillas that kept peeking around the corner and I kept going get the hell away from me, I want nothing to do with you. I am the CLI jockey, right, like that's the job.

Speaker 1: 13:49

And I was brought up maybe in a different time. That was the whole program. I went to Netacad Like that was the job. So fast forward, years later I find myself.

Speaker 1: 13:59

I fought all the changing landscape as long as I could and then I thought if I could run away to a vendor and just smile and be charming and help customers be happier, like, oh, this is great, I don't have to study anymore and screw that automation stuff. And then I got laid off in December and I started looking at job postings. I'm like shit, they all want automation. You have to know Python or Ansible Infrast. All want automation. You have to know Python or Ansible Infrastructure is code. You have to be versed in a cloud. So really, for me it was only out of. I was beaten in a submission is what I'll tell you.

Speaker 1: 14:36

The industry has changed. If you look at job postings today as opposed to even five years ago, I have a lot of people come to me Because we do a lot of work in the community helping people, and I probably have seven people right now I'm trying to help with resumes or trying to get into the industry. What are they doing? And what I told people five or six years ago get your CCNA, do some content creation so you can show your soft skills, your communication skills, and build a home lab. It doesn't have to be physical, but you're not going to have experience and people are going to call you out in interviews and a home lab can show you have experience. We don't have any production experience. Well, the hell, I don't. I got four 2911s, I got 3750s Whatever right and I got a server. So it's a way that I got around the no experience thing.

Speaker 1: 15:15

So I say all that to say that the past I don't know. Six or seven months I've been learning Python. I've been learning GitHub. I haven't gotten into cloud yet, but that's kind of next on my radar. I'm reading an LLM book right now that Phil Gervasi just turned me on to, so I'm trying to get caught up in all the things I avoided all those years.

Speaker 1: 15:35

There's nothing like unemployment to wake you up out of your cognitive bias and re-change your compass of like, oh, just because I don't want to learn automation. Nobody gives a damn. You know what I mean. And if you're at a job that you don't have to do any of that, good for you. I was in a job. I didn't have to do any of that. I'll end with this. The job that I had for six years that I was a senior at Edge ran all the WAN projects. They wouldn't hire me Python knowledge. So I can't even get the job today that I got before at the same company. I was a rock star there. Just because I'm not Python proficient, I'm getting there. I just ran my first script in NetMeco and I logged into a router and did a show for in whatever my just visual studio code. And I'm also learning Linux. Right, these things that, like it was on Scott's thing earlier Linux automation, you know all that stuff. So it is changing and I'm just busting my ass now trying to catch up.

Speaker 5: 16:30

I'm the cloud guy, so I've got to say that the biggest change has been the rollout of the cloud. And it's not just that hyperscalers exist, but they put a pressure on the way that everything else is done Because they're the 800-pound gorilla, they're the 2,000-pound gorillas in the room. Else is done because they're the 800 pound grill. They're the 2,000 pound gorillas in the room. They're the ones who can drive the design of specific ASICs that are going into network gear. They can determine how system boards are designed for the compute that they're running. They have a lot of influence, I guess is what I'm saying. And their philosophy is everything needs to be programmable, everything needs to have an API and everything needs to be automation friendly, because there's no way we can do this at scale If somebody has to click on next, next, finish. And you know, I came from desktop support and a world of Microsoft where a lot of stuff was next, next, finish, and I also had to learn automation slightly different context, but same basic thing.

Speaker 5: 17:27

I was managing Exchange 2003 back in, you know, 2003. And then Exchange 2007 came out and, for those who don't know, exchange 2007 was the introduction of PowerShell into the Microsoft ecosystem for real, and there were certain things you could only do in Exchange 2007 through PowerShell. You couldn't go into the GUI anymore, and that was great for big organizations who were like we want to run these scripts at scale and do things, and it sucked. When you're an SMB and suddenly you are also responsible for writing PowerShell, you can guess where I was. But it forced me into the world of automation and by doing that I learned PowerShell, which is scripting, programming, call it whatever we want. But then I was able to apply that skill to VMware and then I was able to apply it to Azure.

Speaker 5: 18:21

When that rolled out and then, after realizing that using PowerShell to control Azure is kind of a pain, I discovered Terraform and I was like, oh okay, so I can do this declaratively now. But the core premise of Terraform and all these other tools is the fact that there's going to be an API you can talk to. So I guess the biggest change is the fact that you have to shift the mentality a little bit away from the CLI and on to how do I interact with an API or write a tool that knows how to talk to the API? And that's been a struggle for me as much as it's been for any network engineer, but slowly we're all getting there right?

Speaker 6: 18:57

Yeah, it's hard to disagree with anything that's been said. I think, as Scott mentioned earlier in his presentation, networking sort of fundamentals have kind of we're not fighting about TCPIP versus ATM or whatever. We're not battling over token ring versus Ethernet. That's been decided already and now we've got that structure and we're building on top of it in a data center. It's LeafSpy and EVP and VXLAN and we don't need to argue about it anymore.

Speaker 6: 19:20

Where things are going is toward automation, is toward more software, developer-like constructs like GitHub, like APIs, like being comfortable with Python, ansible and these new tooling things. Cli skills that you put a lot of work into may not be as relevant, but the thing that is still relevant is all of that fundamental information that you have about how IP works, about how Ethernet works, about subnetting, about addressing. That's still essential, regardless of whether you're doing it in the cloud, on-prem, through some new software interface or right into the CLI. So it's not an abandon all hope. You've got the fundamentals that are essential now, like this gentleman from Oracle said, oracle doesn't have a cloud business without a network.

Speaker 5: 20:03

Somebody had mentioned I think it was, I forget which one of you, and I'm sorry. Staffing is a major concern Finding people that have the fundamental skills and that when you onboard someone, it's more about a history lesson because they don't know that stuff. Maybe they're an expert in Python but they have no idea how to set up a trunk for VLANs. They're like a V, what I'm not familiar with the terminology, and so if you already have those core skills around networking, you understand the fundamentals. Like programming is hard but it's not that hard and I mean I've seen people that have learned programming. I guarantee you can all learn it. Um, what's really really hard is the last 10, 15, 20 years you've put into learning network fundamentals and that's something that's irreplaceable and someone can't just accelerate that in a three-month course and suddenly understand all the fundamentals. So you got to leg up on people. That way it it's just you have to continue to learn and grow your skillset to accommodate the tools that are driving that underlay.

Speaker 2: 21:05

So I do want to pass the mic around the room here a little bit as well. Right, thinking about where they've seen things come from to where they think things are going. Anybody with a strong opinion in the room? Just relative to some of what they mentioned? It sounds like cloud and automation, two of the big ones. Right, I'm sure we can all agree we're seeing some of that within our roles and what we're doing now. But is there anything else you're seeing outside of those two realms that you think is pertinent to what we're talking about when we look at where network engineering or engineering in general is headed?

Speaker 7: 21:34

So one of the things that I've seen, I've experienced, is we went through a huge data center migration right, and part of it is networking right and you're part of that team to migrate apps from on-prem to now into AWS right, and you're kind of forced into the cloud world and, like you said, there's networking component, transit gateways, and you're also, as a network engineer, expected to understand security right, and so that's a skill that you know we haven't touched on tonight, but you have to know it right, because there's networking in every firewall that you touch right.

Speaker 7: 22:15

There's BGP, there's OSPF right, and if you're going to do direct connect with AWS or any of these other cloud providers, you have to understand that stuff right and you have to understand how you're going to. You know peer with other network, you know with your AWS cloud and everything like that. So I think that's one of the things that I've experienced is that traditional networking is a great base when you have to learn cloud skills. Once you get into the cloud and you're like, oh, these are things I've done for the last 20 years, it's that much easier.

Speaker 2: 22:49

One of the interesting things about the networking industry and I'm saying this as not one of the panelists so cut me off. If Andy later on edited it out, go ahead. So cut me off. If, like Andy later on edited out, go ahead. But at times you almost have to become, because the network is touching everything right and you have people that are specific to individual domains, like you mentioned. You know you're going to have security, you're going to have infrastructure, you're going to have network, so on and so forth, but you almost have to be in some way, shape or form, kind of like that jack of all trades.

Speaker 7: 23:15

You do Network or form, kind of like that jack of all trades. You do and you are, and and for lack of better term, you're sometimes you. You get asked to join a call, right, and you're the adult in the room. You are, you're the adult in the room because it's seven spider-men just pointing at each other, going right, and we're of. We're like almost like the blameless society, or we're gonna. We're of, we're like almost like the blameless society, or we're going to, we're not blaming, like, just tell me what the problem is, right, and then let's break it down, right.

Speaker 7: 23:43

And so, as network engineers, I think that's part of our job is to be that adult in the room and to be able to say okay, you're on the application side, what are you saying? Show me your screen, show me the code that you're running. And it's like you're looking through their code. And you go oh yeah, that you didn't in your request, you didn't request that URL to be allowed in the proxy, or you know, or in URL filtering, you know like. And they go oh yeah, sorry about that. And you're like OK, hold on two minutes later, and then everything's working Right. Like, okay, hold on two minutes later, and then everything's working right Because you looked at someone else's code, because you understand Python, you understand Ansible, you understand all these languages, and so being able to look at what other folks are doing and find that needle in the haystack is almost invaluable.

Speaker 7: 24:33

So, you know, being that jack of all trades is really important and I think that's the biggest skill, like if you're interviewing and you're, you know, giving advice, like that's one of the big pieces of advice that I would get. Be that jack of all trades, know a little something about everything you know, learn how to be the adult in the room.

Speaker 9: 24:51

Just kind of piggyback off what he was saying. Even getting once you're, you know, get the DevOps into that cloud environment, setting policies and procedures of spinning up specific VMs on weekends and letting them run in a test environment, but who's getting the bill? The infrastructure team, and it's a complete disconnect. You're spot on about that Policies and procedures and bringing them together along with security in those conversations, but that's very valid. And even having to rely once you get to the cloud, then the vendor teaching you AWS or Azure, or having to get up the ramp but so many companies are running so lean right now they don't have time to learn it, so it's very valid.

Speaker 1: 25:30

When you said you don't have time to learn it. That was my reason slash excuse. For a really long time I was working three to four maintenance windows a week. You know what I mean? I had little kids at home. I was exhausted just keeping the lights on. They're like and, by the way, you're going to learn all this automation. I'm like when, right, like when am I supposed to do that? Now I'll take responsibility, because my manager did tell me Tuesdays you can work on automation learning, and there was so much work and I didn't say no, like well, I gotta work on scripts all day, tuesday for my Tuesday night maintenance window. So I take responsibility that I should have said no to work that they said was supposed to be for automation, but that I just didn't have the time. So it always comes down to like nights and weekends and, like you know, oh, the kids are in bed. Now Let me go like learn some new stuff. But got to figure out when.

Speaker 10: 26:15

Yeah, so mentioning things where I've seen things change over my career and being in just enterprises for the last 20 years and from when I was coming up in the beginning I had to become the CLI jockey, get in the routers doing everything that way and then eventually got into automation. But that was, to Ned's point, that core understanding that I built up over those 20 years of being in the networks firewalls, low balancers it helped me be able to be more proficient and get ahead faster because all I had to do was learn a little bit of Python and that propelled me that much further. But what I noticed was some of the when we bring in interns or new people trying to break into networking, or even somebody who said they had been in networking for a few years, they would come in with a whole lot of ClickOps knowledge. They only had access to a GUI or a Meraki dashboard and they came in saying I'm a seasoned network engineer, but they didn't understand what they were doing.

Speaker 10: 27:20

They didn't have those 20 years behind them. So they're like oh, a VLAN, you want a VLAN? I know how to put that in. I go click, click, click. Here's a VLAN. Okay, here's a trunk. I turn on this port, but they didn't understand the impacts of what they were doing. I saw a lot of that kind of going away as that age of GUI came along and hopefully that stuff is starting to disappear as the age of APIs are coming in more and that stuff becomes. That back-end knowledge becomes more important and I think that's one of the reasons why there's not as many strong engineers that were coming up in our career path right now because of that disconnect for a few years where they had a lot of click ops engineers that are now being replaced with guys coming in with that Python knowledge.

Speaker 4: 28:09

So I think it's more of a question, but I guess do we see a future where right now there's not a lot of young people coming out of college saying they want to go into network engineering and so when you're hiring a junior engineer you know it's probably limited? Do we see a future where we're hiring programmers that then are coming in and learning networking instead?

Speaker 3: 28:28

I don't think so. It's still TCPIP. I mean, how many outages are caused by BGP and DNS? The TCPIP like learning how you know all this stuff works. It is critical. You can't come in and spend all your time with code and then just haphazardly pick up how okay, like you know, even doing a packet walk okay, okay, we're bits, Now we're going to frames and we're going in this interface and now we're packets. We're going through this routing protocol and now we're advertised to this.

Speaker 3: 29:01

Like that's one thing that I used to do in job interviews. I would actually set up a lab and when people would come in, I would have them do actually very simple things, just very simple things, and then you could say, okay, on their resume, they're an expert at this, but then they couldn't follow something on a single device. They're an expert at this, but then they couldn't follow something on a single device. So that tells you a lot. So having the and it doesn't, it's not easy to learn those things.

Speaker 3: 29:23

I have like these gigantic TCP IP books on my shelf at home that I referenced back to a lot, Cause that knowledge leaves you pretty quick too. You really have to keep on it, you know. So I think the counterbalance to that is partnering with a software developer, and this is something I did at one of my previous organizations that I worked for is we had some folks that were like high quality software developers that sat with us for probably like 20 of their 40 hours and not only did that help me I mean I thought I was a good coder at the time and that showed me that I wasn't a good coder and there was a lot of stuff I could improve but it helped the team, it helped with the knowledge sharing and it was like a very, a very cohesive relationship, because nobody can be an ex. Well, you do have folks out there that you know, seemingly are photographic memories and experts at so many things, but for the you know most of us, you, you can't be an expert at all these things and you have to pick what you put your time into.

Speaker 6: 30:19

I will say I think that in some cases maybe, yes you will have to hire a programmer to do networking jobs if not enough people are going. What is the track now for someone who wants to be a network engineer other than going through the Cisco training program? How would you decide that that person's a network engineer that I want to hire? I think if we're seeing a decline in folks coming into network engineering, it means that the industry has to work on maybe something more like an apprenticeship model where we don't expect to hire somebody, you know, day one who's going to get into the routers and do what needs to be done right away and have that fundamental knowledge We'll have to go through. Maybe they did a CS degree and they're comfortable with something like Python or Terraform, but we're going to have to help them then get those fundamentals and networking if the discipline is going to survive.

Speaker 5: 31:05

I was just talking to. Well, just, this was like two months ago, but we'll say just I was just talking to someone who recently graduated from Temple University with a CS degree and she got a job at Comcast and I think that episode just published last week so you can go listen to it. But to summarize her experience, she didn't learn any of this in her CS degree. She learned how to write in C, she learned how to like cobble stuff together in various programming languages. She didn't learn anything about CI, cd or pipelines until her final senior capstone project and even then it was kind of optional, like they didn't learn anything about CI, cd or pipelines until her final senior capstone project, and even then it was kind of optional, like they didn't learn about GitHub and I'm like come on. So I think it's unlikely to expect someone to come straight out of college and be ready to be a network engineer or any other technology job aside from throw them into like a junior developer role. She was very lucky to land with a team that has a strong culture of taking junior people and giving them the room to make mistakes, helping them to learn, helping them navigate the system, and she's now been at her job for a year and she's learned a ridiculous amount of stuff about different topics by being curious and having a culture where she's supported to learn.

Speaker 5: 32:22

So, as much as we want like perfect engineers to kind of walk in the door, it's unrealistic and I know for those of you who are not in management or hiring you don't get to decide the budgets, and if they give you enough budget to hire one person and you've got all this work to do, you want that engineer to walk in the door and be like I hire you, you're good, let's go.

Speaker 5: 32:44

I would hope that you would be comfortable to push back a little bit and say I would prefer to hire a junior person. It's going to be a little harder for a while. We might not be as productive, but we only have to pay them like half and then they're going to get really good and then you know we'll we'll pay them more and then we'll bring in a new junior person that we can train up as well. So I think it's as much on those of us who had been in the industry for a while to help create that pipeline and find the curious people, cause I know they're out there. I know there's people that are hungry to get jobs and learn a skill. We, as the more senior people, need to be willing to help them along that pipeline as much as we want to help ourselves.

Speaker 11: 33:29

So the things that I've been stringing together here, like there are different employers Expecting a fresh new college grad to know it all and be ready for everything that's never been realistic, right. And like there are legendary programs like Sprint had a program called the Associate SCE program where you got hired and then you spent 12 weeks taking 12 week one week long classes, testing and you got to pick your assignment based on how well you did in the program. Cisco's had a great associate se program. Juniper has gone up and down with it, um, and I participated in that right, um, and those are all good things, but none of them are enough and I want to get this on the record here.

Speaker 11: 34:22

I think USNUA could make this an emphasis. How do we do outreach to new and career people and non-traditional? I think that's another channel that we've just not developed. We all know so many people who got into this without a college education, right. And the things that you don't need a bachelor's to do help desk and to do so many other things right. I think we can do more things together. I think if we could find a way with US and UA and confederate with NAF and NANAG and maybe put some other industry programs in place. I don't mean this as a rebuke, but I'm tired of identifying the problem. I would like to start doing something about it, so I'll stop there.

Speaker 1: 35:14

I just wanted to wrap that part of it up. My concern is that the networking vendors are going to monetize the lack of people coming in. Their automation is going to get so good with their little AI assistance. And I don't I shouldn't have said little because, no, I'll be honest with you. I was just doing some stuff in SR Linux and they had this. I was talking in the CLI in natural language, and it gave me exactly what I needed.

Speaker 1: 35:43

That was a very different experience for me as a 15-year network person. So I see the advancement and I think it's much more likely for a vendor to figure it out and have one engineer do the work of 10 because their software is getting so good, as opposed to how we're going to get more people in. We're going to go on a national tour and talk to high schools. I think it's going to be hard. Like people don't want to be plumbers, I think trade schools are down too, so we're the plumbers of the internet, right? So my crystal ball is vendors are just going to monetize it and we're actually not going to have to plug that gap because you're going to do the work of 10 in a couple of years, because the software is going to get that good? I don't know.

Speaker 3: 36:14

Well, this is already happening in the startup space, though, like startups are expected with these AI agents Okay, you have basically the knowledge of a few PhDs. So it's shrinking the size and the staffing of some of the newer startups that are coming to market, and they're expected to do way more with less, because you know that means everybody gets more, you know, more capital at the end of the run because there's not as many people involved.

Speaker 12: 36:39

So I think it's all very good points about educations and different ways to come into the networking career field. When I first got into the networking career field, the idea of having a Bachelor of Science, even in being a network engineer or even a senior network engineer, was a foreign concept for a lot of individuals. I'd like to see us move back in that path. A lot of the network engineers that I know came up from that path. They were found playing laser tag. They were working in a laser tag store or they were working at a gas station and they wanted to improve their life. It was a career path to them, for you know a better way. The thing with the AI comment and how AI is going to generate all the commands that you need I think the one piece that I've learned along the way is there still is going to have to be somebody who understands that underlying protocol.

Speaker 12: 37:27

I remember implementing my first Versa SD-WAN solution when it was on 15.2 and they had no flows or anything else to go about it and I sat down with their engineers to figure it out. We were doing all those buzz terms to make the product better week after week, no flows or anything else to go about it and I sat down with their engineers to figure it out. We're CI CD. We were doing all those buzz terms to make the product better. You know week after week, but you still had to be able to go in there and understand what was going on at the packet level and how it was going out. It was being deconstructed, being put back together. That is where the network engineer is going to excel in the future. If they're not still understanding the history and what's actually going on at the frame packet level and even lower, we might not see as many network engineers, but the level of expectation of knowledge you're going to need is going to be much higher, in my opinion, to be an efficient network engineer. Maybe.

Speaker 1: 38:16

For the same salary?

Speaker 12: 38:17

Yeah, for the same salary yeah, for the same salary, it's not going to change much you're going to do four jobs for the same, right.

Speaker 1: 38:21

I mean, that was part of my resistance when all this stuff came like I got I got to be a network engineer, I got to be an automation engineer, I got to be a cloud engineer. I got like really one salary for all. But that's just, I think.

Speaker 12: 38:32

But that's what's happening, right, that's the job we saw that in other engineering disciplines as well. Think about the 1950s. You saw drafters. It took an entire room, or two rooms, of drafters to come up with an aircraft. Now you have what? Three dudes sit down in front of a computer and bam, now you produce the next Boeing 777.

Speaker 8: 38:50

This kind of dovetailing off what he said. I mean, I think the larger question is how do you become a professional? How do you become a professional at anything? Forget networks, right? I mean, if you want to be a rocket engineer, you don't go study rockets, I mean, you study physics. And how do you study physics? You study math, and math is the base principle of putting a rocket.

Speaker 8: 39:09

If you want to go into the military, if you want to figure out how war works, you go study wars from hundreds of years ago. Right, I mean, there are base principles of logistics and things that go into codifying military science, right. So, like, if you want to be a professional at anything, you have to know what the base principles of, and ultimately the base principles of networks are electrical engineering, algorithms, distributed systems, computer science, everything else on top of it, the cli and how you automate it. I I mean, that's all like recent stuff. But if you want to, like he was saying, like, fundamentally understand or be a professional at this discipline, go study math, you know, and you'll be able to apply it over and over and over.

Speaker 8: 39:51

I'm a, you know. I was telling at the break, like you know, I was kind of foolish enough to get two CCIEs back in the day. But honestly, like, the undergrad in computer science is worth so much more and a master's degree is worth so much more. It teaches you how to think and if you know how to think, you can apply it over and over and over, like just knowing. Cisco CLI is a fad.

Speaker 5: 40:13

I think about how young the tech industry is as a whole. I mean, you know, plumbers have been around for hundreds of years. That's a trade that's been around for a little while. Think about all the other industries out there that are hundreds or even older. Tech is what? Like 70 years old if we want to be generous, 40 years old if we want to be slightly less generous. So if that's how long we've been doing it, there's still a lot more to learn. We're in the infancy of technology and I think you're right to a certain degree. Just having fundamentals that are beyond technology and going into concepts that never get old, like math basically, and being well-versed in that, will guarantee that you can find a spot somewhere. But I don't think everybody wants to do that. I think you're going to have people who are comfortable being generalists and for the listeners I pointed at myself.

Speaker 5: 41:14

I came from help desk, I went into sysadmin, but I worked at a small company, so we were responsible for everything. When I said everything, if the air conditioner broke, I had to call the repair guy to come out and fix the air conditioner. If the vending machine was empty, I had the keys to go open the vending machine and so, coming from that, I had to understand how a storage array worked, how networking worked, how VMware worked and also some weird stuff about Microsoft Word that I don't even want to get into. But I had to have that sort of general knowledge and I was comfortable with that. I've never been a go deep on one thing and just be an absolute expert in that one thing and that's just. I know that's me, that's the way I am, and I think that's kind of where things are headed.

Speaker 5: 41:57

You can either be a generalist in the cloud or a generalist with technologies, or you can go super deep on one thing. Vendors are going to eat out the middle, they're going to go. We can make it good enough. We can make a Meraki where it's close enough and easy enough to click ops your way through it, that any small business or even medium business never needs to open a CLI because they can just click through and connect all the cables and it just works. And if you're a generalist, that's perfect. And when something goes wrong they can call the network engineer at Meraki, who is the deep expert, and they'll figure out what's actually going on. And I think that's the case across all technologies, not just networking is that soft middle where we needed someone with those skills. That might be shrinking and you either have to go deep or wide.

Speaker 13: 42:43

I've been working computers for a very long time. When I got into it there was no Google, so it's funny seeing it grow. So it's like CLI, that's all there was back then. I've grown up through computers. My son's now 25, working for a pretty big VAR and he's kind of learned similar stuff Also on the network routes. He's doing segmentation and it's funny seeing the differences.

Speaker 13: 43:05

So where I grew up with CLI he was the opposite. He's kind of gone the gooey route because that's what they've learned. And as someone also who's hired people out of college, what I'm kind of seeing is the tools are getting better for networking and you're going to see a lot of ways to make what you used to do back in the early 2000s and even before that. It takes a very long time. Things can get quicker, but when it really breaks those tools are not going to be as good and that's where you kind of need the people who do know what they know. The people that worked at the bottom of the OSI stack and up the way up know that stuff a lot better than the people who start at the top and work their way down.

Speaker 6: 43:43

Yeah, but that's something that comes with time and experience.

Speaker 13: 43:45

Yes, so yeah, and that's the thing. So it's like when, when I hired, we hired a kid out of college great worker, he is a junior person now sent him to send him to training so he gets experience, which is great, he learns his stuff, but the big thing is he's shadowing the people that they they may have learned the books, but they also learned where it's important in the real world, because the books don't always tell the truth in a way, but that that's yeah. That's where they have to learn is is the younger kids need to work with the older ones that have been around so they can then see where you know it doesn't always work the same way.

Speaker 2: 44:21

So we we have about two minutes left, Um, and then I think we hit an hour, which you guys are the experts, but my understanding is you go over an hour on a podcast. People stop listening, that's what.

Speaker 9: 44:30

I'm told anyway.

Speaker 2: 44:37

So I want to be cognizant of that, but I did want to pause, you know, ask for closing thoughts just relative to the conversation. Right, Much like our past nugs, we got through a total of one question today, which is great. Just love to do that. It's good because it means that everybody's involved. Right, the conversation's happening and that's really what we want when we're here. But just want to ask for closing thoughts before we kind of move into more of a wrap-up and we kind of close the event out here.

Speaker 6: 45:01

Yeah, I'll start. First, I'm excited that there was so much back and forth, like we didn't just want to come up, so I appreciate everybody weighing in with their experiences. That was great. It's great to have more of a conversation. Second, I'm excited about the future of networking. I think there's a ton of interesting stuff. So, ladoo, really fascinating problems to solve and I think if we pitch it the right way, we can bring in a new generation of network engineers and catch their curiosity and give them all these cool tools and let them go play and do incredible things. So I'm rosy about the future of this discipline.

Speaker 1: 45:32

It's a great career, right, I mean it's a great job. Nobody likes change. I saw a lot of change. I didn't like it. I cried, Nobody cared, Got laid off, panicked, learned a bunch of new stuff and now I'm in a better spot. You know what's different from now than my 2012 CCNA? Learn Linux, learn automation, learn cloud. I think if you can learn the fundamentals of networking and those other things, I think you're in really good shape.

Speaker 3: 45:58

I feel compelled to make my closing thoughts about AI. So seriously, though I almost came like with the AI stuff I was what I'm seeing it's kind of scary almost is one of the big skills over the years that I learned from not having Googled everything and having an answer immediately available. Was it kind of the gentleman's point back there? It helped me think and work through problems like I had to figure it out. I couldn't just type into chat gbt how do I do this? And get an answer immediately. Because when you do that for everything, you find that's how you train your brain. That is the training that you're taking in. You're not actually building a skill set and that's something that I honestly kind of scares me. But I know that AI is going to be a big part of the future and I was just in New York and I don't know if you all know who John Capobianco is. He is really bullish on AI and he actually made me excited because he sees the good and where it's going and he kind of narrows into where the real value is and is super excited about it. So that's just a reminder to me that all these new technologies about it. So that's just a reminder to me that all these new technologies, you can't discount any of them. You really have to see where they're going to be practical.

Speaker 3: 47:16

But again, how you use that chat GPT, like I know that I could go in and say, hey, I want you to write this code for me, but I still make my it's hard, but I still make myself.

Speaker 3: 47:27

Not do that. I might give it some of my code and say, hey, what is wrong with this? But don't give me the answer. I don't want you to give me anything back and I can get some feedback and then go and figure it out with less stuff. And I know that's still kind of cheating, but at the same time I still want to keep sharp so I can actually write things and I know how it works and I know how everything you know connects together. So yeah, just I guess my feedback and closing argument is you know there's a lot of stuff coming our way and you only have so much time. You know, try to prioritize and do what's best for you and your role. You know what you're doing with your job, cause if you can apply it practically, you know it's going to stick better and it's going to serve you better long-term.

Speaker 2: 48:09

With that we'll. We'll close it out there. Again, appreciate everybody's time. Thank you for the panelists.