Russ White: Will AI Replace Network Engineers? (2026 Answer) | The IT Director’s Podcast

Facebook
Twitter
LinkedIn

Russ White Joins The IT Director's Podcast

In this episode of the IT Directors Podcast, hosts Jay and Michael sit down with Russ White, Ph.D. — Principal Architect at Nokia. He has decades of experience building and designing large-scale networks for companies like Cisco, LinkedIn, and Juniper. Russ White holds the distinction of earning the very first Cisco Certified Design Expert (CCDE) certification in 2007. Beyond his technical certifications, Russ White hosts his own podcast, The Hedge, and holds a PhD in Philosophy — a background he says has fundamentally shaped how he approaches network engineering. In this conversation, Russ White breaks down the real trade-offs of network automation, explains why AI should be used to validate and stress-test systems rather than build them outright, and offers his honest take on whether AI will ever fully replace the human element in network design.

Russ White: Will AI Ever Replace Network Engineers?

Jay: What’s going on? This is Jay and Michael here on the IT Directors podcast. Michael, how are you doing, bud?

Michael: Man, it’s an awesome day today. It’s, it’s midsummer — I mean, it’s hot, but we’re doing well.

Jay: We are doing well, yes sir. Hey, look, we have a fantastic guest for our listeners and viewers today.

I’m super excited. A lot of people probably know this guy — world-renowned Russ White. Russ, welcome to the show, the IT Directors podcast.

Russ: Thanks. World-renowned — oh my goodness. Just an average guy doing average stuff. That’s all I am.

Jay: Hey, I like it — I like it so much. I mean, look, Russ, 20 years building, fixing, designing, and architecting large-scale networks. Working at organizations like Cisco, Juniper, LinkedIn, Ericsson, and — what is that — Akamai? How do you—

Russ: Akamai, yeah. And now I’m at Nokia.

Michael: Okay, Nokia. And then you’re one of, probably, a handful — what are they?

Jay: 1,500 Cisco Certified Architects at the level you are, worldwide, around?

Russ: Okay, Cisco Certified Architect — there are, I think, ten. And they killed the certification, so there are no new ones. There haven’t been new ones in a long time. I guess we still hold it, but nobody really cares because it’s—

Jay: Yeah, yeah, yeah. I knew there were a couple in the Cisco realm. I knew there was one where there were, like, 1,500 people worldwide, and I knew there was a handful—

Russ: — that was in the CCDE. I think the CCDE is growing now, I don’t know. But I’ll tell you a little trick if you want to know how long somebody’s been a CCDE — other than the number containing the year, if someone has a 2007 number, there are only seven of those, and those are the seven people on the team that designed the CCDE.

So if you see CCDE 2007 colon whatever — there are only seven of those, and that’s the first year it was out there.

Jay: That is fantastic. And, hey, you host your own podcast, The Hedge.

Russ: Yep.

Jay: All of our listeners and viewers, go check it out — go follow The Hedge. I listened to some of it while preparing for this show, and I’ll just tell you, our marketing team is on cloud nine having Russ White on the show.

Michael: Oh, yeah. You’re an internet phenomenon on LinkedIn and on your podcast, and just your wealth of knowledge around networking — being an author, Cisco, all these things. Yeah, and we’re really looking forward to our conversation. Appreciate your time today. And I think one of the things we want to talk about is distinguishing the hype from what’s real versus the noise. I think there are a lot of people on either side of the ditch right now, and truthfully,

Russ: Oh,

Michael: — the road has two ditches. You’re going to find yourself on one or the other, and I think when you have that experience, it helps you understand the big picture. And so,

Russ: Yeah.

Michael: — that’s definitely something we want to talk about

with you today, too.

Jay: Absolutely, Russ. You know, we’re an MSP, so we service hundreds of customers across all different verticals — government, local, K-12, healthcare, law firms, automation, manufacturing. I just got back from AI4 with our owner, our VP of engineering, and our director of development, and, man, it was incredible. But, Russ, it was so interesting because a lot of what we heard, Michael, is a lot of what Russ talks about and a lot of what we’re going to talk about today. I don’t know if you were there, Russ — it was AI4 in Las Vegas.

Russ: Nope.

Jay: A great conference.

Russ: Yeah.

Jay: It was neat hearing from some of these people in that space, globally.

But, hey, let’s just roll into our questions, Michael. I’ll go—

Russ: Yeah.

Jay: — off here. So—

Michael: Yeah…

Jay: I mean, you have an extensive background in network engineering. You also have a PhD in philosophy. Does your philosophical background influence how you approach networking, Russ? And if it does, how—

Explain that to us, and tell our listeners and viewers about it.

Russ: Sure. So people call my PhD in philosophy a recreational PhD, which is kind of funny, but that’s what they say.

Michael: That’s a lot of work for a recreational hobby — that’s some serious work right there.

Russ: It’s true — PhD programs wander all over the place. But the one I went into, at Southeastern Baptist, was run by a guy named Bruce Little, my major professor, and it was a lot of work — tons and tons of work. I mean, reading over 300 books, writing ten or fifteen twenty-page papers, plus the dissertation, the comps, and everything else.

And so it was a serious, real PhD program. I’d say there are many things I learned — or, well, a lot of people have this misconception about the PhD, that you’re going to go in and learn something. The reality is, all you learn in a PhD program is how to research and how to teach,

Michael: Mm-hmm.

Russ: and the topic is almost orthogonal.

It’s like, “Oh, we really don’t care what the topic is.” I mean, we do care — people do care what the topic is — but, by and large, I took a lot of classes on teaching and all sorts of stuff on research and research techniques. The other thing that’s been really helpful for me is the mental discipline of framing arguments. In philosophy, you don’t get away with sloppy thinking.

Not in the program I was in, anyway. No slop allowed. You can’t just say things — you can’t just throw stuff out there. My major professor, Dr. Little, used to do this thing in class all the time. They weren’t really classes — they were seminars, with only five or six people — and he would ask a question and let everybody around the table give their answer. He’d listen very patiently, and then at the end he’d look at you and say, “I would agree with you, but then both of us would be wrong.”

Or he’d say,

Michael: Uh-huh.

Russ: — he’d say things like, “There are only two things in the middle of the road: dead possums and yellow lines.

Michael: Okay.

Russ: Make up your mind.”

Like, make a point — don’t be in the middle, don’t try to make everybody happy, make a point. Those kinds of mental habits. The other mental habit I developed through the PhD program is that I’m very particular about language now.

I’m so… Technical language and communication in general became so much more important once I’d gone through philosophy. People mean something when they say it, and once you go through the epistemology, you try to understand that. So I think those are the biggest areas where I’ve looked at the way I do network engineering and said, “I actually need to be more precise about my language.

I need to think about when I’m presenting something — telling a story, not just dumping information. I need to think more carefully about the way I communicate, and about the way I think about things: the way I form arguments and the way I go looking for opposing views and for where things can fall apart.”

I think those are the big things where it really intersects. There are all kinds of other things, too, but that’s… go ahead.

Michael: That’s awesome — no, I appreciate that. I think the intentionality with which you approach things really shifts and changes how you think. When I was going through one of my programs, one of the things that always bothered me was that the professor never would answer a question.

He’d ask a question and not give you an answer, and you were left to work through it yourself — not just to provide a response, but to understand the whole point behind it, and to back up anything that came out of your mouth. You had to be willing to back it up, and

Russ: Yep.

Michael: — truly back it up. So, no, I appreciate that.

Russ: Yeah.

Jay: Fantastic. And one of the things, too, Michael — Russ talked about how it changed the way he designs, engineers, and architects networks, based on his communication and being precise and thoughtful, and also being willing to understand different philosophies in networking. Because, look, in my experience, being in the industry for many years — and, Russ, you know this, right?

At a high level, most engineers think they’re the smartest guy in the room all the time. Any network engineer you ever—

Russ: Yep.

Jay: — [think] they know everything about networking, and that’s really not the case. It’s really inspiring to listen to someone like you talk about the philosophy, the communication, and the thoughtfulness behind how you technically document and engineer things, because I think that’s key.

Because that reaches the human element, right?

Michael: Yeah, yeah. I know you said the words “human element.” I know part of our conversation is the human aspect, and then AI and what AI is doing in this environment today. So another question we had was — you know, when we see so much automation happening, so much implementation of AI, in companies and industries across the board — here’s the question we wanted to ask you.

When a company automates part of the network, what trade-offs come with that, and are the benefits significant enough to outweigh them?

Russ: Yeah. There’s always a matter of trade-offs, right? I always say, if you haven’t found the trade-offs, you haven’t looked hard enough. Some people think that sounds mean, like, “Oh, that’s—” No, it’s just the truth. That’s the way things are in life. If you haven’t found the trade-offs, you haven’t looked hard enough.

And I think, when you look at the trade-offs, what’s really important is thinking about where those trade-offs are going to show up. So when you say automation, what are the trade-offs? Well, to me, when I think about an automation system, the trade-offs come in things like having way too much information to deal with now.

I can blow up the network bigger than I ever did before, because a fool with a bad tool is worse than a fool without a tool at all, right? And so you’ve got to be very careful about that stuff. The other thing is that it can actually increase brittleness. If you think about it — say I put in an automated security system in my house, even something as simple as door locks — all of a sudden you think, “Well, the door is now secure.”

But the problem is you’re counting on the door to do the right thing all the time. If an attacker can find a way past the door — a drill and a Sawzall through your wall, for instance, or a big sledgehammer through the wall in some cases — your door means nothing. So it’s actually increased your brittleness, because you’re relying on something to do the right thing, which has stopped you from being cognizant of, or paying attention to, when other things happen.

So I think automation systems often have this effect on people. You say, “Well, you know what, the automation system’s going to take care of it — I don’t need to worry about it.” No, actually, it doesn’t work that way. You still have to be cognizant. You still have to pay attention. And beyond that, the automation system speeds everything up.

Great — it speeds everything up. It makes your life easier because it speeds everything up. But I can tell you that in some situations, being faster is worse.

And because you overcome human reaction time, you overcome the system’s ability to back itself off, and you don’t think about positive feedback loops and things like that — and that’s how you get into these problems.

So I wouldn’t say it’s always negative or always positive. I’d say it always brings in both, and the negative is that people don’t think about where it’s causing, or potentially causing, problems.

Michael: No, I think understanding the variables has got to be key, and I think sometimes there’s an over-reliance on a process you’ve automated that doesn’t always account for those variables. And sometimes, like we’ve talked to people who don’t figure that out until they’re running into those issues after the fact that something’s already in play. For those who have started that process, what would you say to a team that’s implementing it, has started to find some issues, and is trying to adjust to get the most value out of implementing those automations?

Russ: Yeah, I think it’s about paying attention — really looking at what’s going on, trying to understand it, playing with it in the lab, trying to break it, and understanding what broken looks like. The other thing you can always do is think very seriously about how you’ve divided up your complexity, and about which automated systems rely on other automated systems, and how those things interact.

A very good skill here — people talk about this. Somebody said this on X the other day, and I responded. They said, “Is it really valuable to learn to code anymore? To actually be a full-time coder?” I said, “Yes, it is,” because you understand the mental process of breaking

Michael: Mm-hmm.

Russ: a problem up into multiple pieces, understanding what the APIs look like, and understanding how to manage information flow in the system so you don’t end up with overwhelming problems.

Michael: Mm-hmm.

Russ: So, to me, that’s a mental discipline, and you’ve got to learn it by doing it. That’s the only way to do it.

Michael: I think the key part of that is also, like what you said, breaking it — finding the vulnerabilities. Yeah, I think that’s one of the—

Russ: Yeah.

Michael: — people are so hasty to try to implement things without even breaking them first.

Jay: No, 100%. And, Michael, internally with us, our VP of engineering always says — he’s a security professional like yourself, and we have a great team — he talks about how just because we can doesn’t mean we should. And I think that’s where AI has brought that “can” to people who couldn’t before, but that doesn’t mean they should, right?

Russ: Right, right. This is why I always think of AI as a way to do code reviews and to bat around problems — if this happens, what are the likely scenarios? Not as a way to build systems, but as a working partner in building the system — as a system that helps me see, understand, and find flaws, as much as it helps build the system itself.

And I actually think that’s somewhere we’re kind of going wrong with AI right now — we’re relying on AI to build things for us, and we’re going to be the humans who react to the failures and fix them. We really should try to intentionally reverse that as much as possible.

Jay: No, I couldn’t agree more. And that kind of leads into our next question: Russ, in your experience, when companies struggle to automate, is that usually because of the AI tools they’re using, or because of the way the team operates and the lack of workflow and SOPs around it?

Russ: I’d say it’s mostly culture. That’s what I see most of the time — it’s culture.

Jay: Mm-hmm.

Russ: People tend to think automation is just a process of building runbooks and processes and then letting it run, and that’s really not how it works. You have to change your mindset about what you’re looking for and how you’re looking for it, and you have to open yourself to understanding that there are new failure modes you need to go find and figure out.

Jay: It’s the human-in-the-loop thing, right, Russ? You know, so, yeah—

Russ: Yeah.

Jay: You hear people talk about that. I’ve heard you talk about it before, and, Michael, a lot of people are talking about it. Six months ago, everybody wanted to automate everything — automate the whole networking stack, the firewall deployments, switches, everything, coding.

But now they’re like, “Hold up, we’ve got to have a human in the loop.” And that’s what Russ is talking about.

Russ: Yeah, yeah.

Michael: And then, even to take that a little further — if it’s a culture problem within an organization, how do you change that culture? How do you walk others through the process of thinking, or approaching things, differently?

Because I feel like that’s got to be the next step. I mean, I feel like you’re a solid voice on this, and your background’s definitely helped you. But for those who don’t have that perspective yet, how do you help people think differently about it?

Russ: Yeah, and that’s… oh my goodness, I don’t know — it’s so hard to walk into a situation, particularly when people have lived their entire lives as engineers implementing and doing things. It’s like taking someone who builds bridges and trying to get them to design bridges.

Jay: Mm-hmm.

Russ: And,

Jay: — a great example.

Russ: — maybe they can do it, right? Maybe they bring experience to the table that the person who’s designed a bridge but never built one won’t have. There’s a blend you need on both sides, and I don’t know. It’s really hard for me sometimes, because I have the same problem in training, too — I’m always much more focused on how something works, and why it works that way, than on how you configure it.

And I think we get really trapped in the “how you configure it” part of the world. We want something very formulaic — a solution, a runbook. You’ve got to get out of that runbook mindset if you’re going to automate, and start seeing the bigger picture. My general technique when I walk into those situations is to try to draw people out, ask questions, and get them to think about…

Ask the why questions. Why do you think it should be that way? Why do you think it works that way? What do you think will happen here? Sit down and tell me five failure modes you haven’t thought about so far,

Michael: Mm-hmm.

Russ: like, what does that look like? Tell me how this network is going to converge.

Don’t tell me how the protocol works — tell me how it’s going to converge. Take a link out. Tell me what happens. Just walk through in your mind what’s going to happen.

Michael: I think that’s good — you’re trying to change that mental loop and process, because I think a lot of people approach this with a direction already in mind. I mean, obviously automation, but at the end of the day, a lot of times it’s about increasing revenue, productivity, whatever. But it’s about getting people to think differently along the way, which I think is also part of the responsibility.

Jay: 100%.

Michael: So do you think — I mean, we’re kind of already talking about it, but this goes to the next question: do you think leaning on AI too heavily is going to negatively impact these organizations?

Russ: Yeah. In many ways, I think, first of all, it knocks out the bottom rung of the work that gets people to think about how it works. That’s a big concern to me — is it knocking out that bottom rung? Maybe if it’s used right, it won’t. Maybe people can use it to learn. I heard somebody the other day — Derek Winkworth — talking about how he uses AI to learn things, because finding training on everything he wants to learn is hard, and he has to read different sources and put things together.

And you can feed, say, four different research papers on the same topic to an AI and say, “Now explain this to me.” So he’s using it that way, which I think is a very good way to go about it. But I think it’s very easy to rely on it instead of thinking for yourself. And the other thing we run into with this is that people…

I don’t know if you’ve ever heard of the Stanley Milgram experiments — Obedience to Authority. It’s a fascinating study about how they put people in an experimental situation with someone wearing a white lab coat, and the person would do almost anything because they believed the person in the white lab coat had authority and was doing the right thing.

We’re doing the same thing with AI — we say, “Oh, the AI says it.” You see it on social media all the time: “Can you tell me if this is true or not?” The AI doesn’t know what truth is.

Michael: Yeah, yeah, yeah.

Russ: It’s a sequencing engine. It’s a statistical engine.

Michael: Mm-hmm.

Russ: Not a truth-seeking being, right?

Michael: It’s going to—

Russ: It doesn’t have… yes, it doesn’t have virtue in the sense of being truth-seeking. It’s useful for research, useful for other things, but it can’t tell you the truth. It just doesn’t have that ability.

Jay: You know, Russ, I couldn’t agree more with what you’re saying about really using AI for learning, training, and automation — and coding. You know,

Russ: Yeah.

Jay: You know, our director of development is a great example of that — a great coder, but we use AI to validate the code and make it more proficient, not the other way around.

And I think that’s really awesome to hear someone with your reach and audience talk about. At first, a lot of people relied on it so heavily day-to-day, and then they had to take a step back and think, “Whoa, hold on a second.

I need to use this just for

Russ: Yeah.

Jay: — and for validation.” You know?

Russ: Yeah.

Jay: That’s how I do it in my role every day, too — I use it more for validation and training. And that kind of goes into what we want to talk to you about next — a big-picture question, kind of a big thought.

Ten years from now, Russ — it’s 2026, so let’s go into 2036, which is crazy to even say. I mean, I can remember the 1980s like it was yesterday, so that’s kind of odd. But anyway, ten years from now, what’s one part of the network team that you believe will always require a human, no matter how advanced AI becomes?

Russ: Oh, I think all of it will still need humans.

Jay: Mm-hmm.

Russ: I think — well, I think we’re going to get to the point where we realize AI can’t do it all, and we’re going to have to back off and rely on humans more than we do now, and think about how to use AI more intelligently.

But I don’t know that an AI system will ever design a truly optimal network, because I don’t know that you can ever define all the requirements for a network. I don’t think you can feed the system enough information — even on the business side — to get to the point where it builds, you know, the truly best, most optimal network you could have.

For instance, I see these really cool pictures of bridges designed by AI, and you think, “Wow, that’s so cool — it did all these weird struts and everything.” And then you think, “Well, but how do you maintain that bridge?

Jay: Yes.

Russ: When one of those struts fails, what do you do?

How much impact does that have? Is it predictable, the way it’s going to fail, in every part of that bridge?” Those are things I just don’t ever see a statistical system like AI being able to do. I’d hope AIs would do things like, “Okay, I see a problem with this link in the network.

I see the human going off and gathering this information — I’m going to gather that information so the human already has it.”

And I can take these basic actions, and after that, I need to flag somebody else.” I can see an AI changing the way we think about admission control, scheduling, and quality of experience in a network — more dynamic stuff.

Jay: I couldn’t agree more, Michael, with what he just said, because I’ve often thought about that — sitting in that conference just last week. As you know, the head of Google Brain, the head of AWS Agentic Agents, the godfather of AI, spoke at that conference — George Hinton.

So we heard a lot of great leaders in this area, and everything came back to what Russ just talked about — I think the shift is reversing.

Michael: Mm-hmm.

Jay: At first we were like, “We’re automating everything, everything’s automation, we’re getting rid of everybody — we don’t need you anymore, we don’t need Jay,

we don’t need…” But now they realize they need a human element involved to validate, especially in networking. How does AI know what the best network design, topology, and architecture is, when all it’s looking at is data?

Michael: Yeah.

Jay: And so it takes the human element out, right? Because there’s so much human involvement in the architecture of a network design — like what Russ has done—

Michael: Yeah.

Jay: — for 25 years.

Michael: It’s those variables — there’s so much to account for, and even those are changing themselves.

Jay: Mm-hmm.

Michael: And I think that’s another key part of it. I’m curious — where do you feel like we are? Do you feel like the arc has already happened and we’re bouncing back, or do you feel like we’re going to head more in that direction?

Russ: I think we’re probably going to overcorrect in the opposite direction before we come back to a realistic center. That’s just what we tend to do in the network engineering market — we tend to overcorrect. “Oh, we just won’t use it at all.” And I know lots of people who are already there, who say, “I just won’t use it at all.”

I understand their perspective, but I think, again, it comes down to discipline — and we’re going to have to learn that discipline.

Michael: Yeah.

Russ: I think probably what scares me most right now is that humans aren’t good at self-discipline. We just aren’t. We’re really bad at it. So I’m really kind of…

The thing that frightens me is that we won’t develop the self-discipline to use this effectively, and it’s going to cause major problems.

Michael: Yeah.

Jay: That conversation yesterday, Russ, with our VP, Michael. We talked about this very thing, and I have a lot of my own thoughts. That’s why it was so great to have this podcast — we get to share our thoughts, and it’s an open discussion, and not everyone agrees. I love AI. I love what it does. I use it every day. It’s ingrained in part of my role, personally and professionally — I use it for automation, validation, and learning, among other things. But it can be used the same way for bad, or for ease of use, where you become kind of mundane in your thinking, right?

Michael: Yeah.

Jay: Then it can be used for improper information, where someone with no idea how to code can build an application—

Michael: Yeah…

Jay: — but has no idea how to fix it when it breaks, Russ.

Michael: Yeah. And then I see so many — I know so many people I feel are in an echo chamber right now, because it’s literally just reinforcing data they’re putting in, not necessarily providing a different perspective.

It’s just affirming your own beliefs. And that’s only going to get you so far, until that bubble pops.

Jay: No — but I think, you know, Russ mentioned it too. I think AI, in five or ten years, is going to be like electricity. When we got on this podcast and sent Russ the link, and he logged on, we didn’t think, “Oh, man, it sure is nice that Russ has electricity — we can see him on his computer.” We just expect to see him on his computer. And I think that’s how AI is going to be. We’re going to see these great, innovative things, and the human element is what got it there, but we’re not really going to talk about AI much in five or ten years — we’re just going to know that it exists, right? That it was the foundation of these things. That’s the JayBirdology, Russ.

Russ: Yeah, no. Yeah, no,

Jay: you got it.

Russ: I totally agree. It’s like the network, right?

Engineering always tends to end up at the point where the way you know you’re doing your job is that nobody complains.

Michael: Yeah.

Russ: You don’t actually get praise for what you do,

Michael: Mm-hmm.

Russ: and nobody yells at you, and that’s

Jay: right.

Michael: Yeah. Yeah,

Jay: yeah. It’s kind of like the guy who cleans the baseboards and

Russ: Yeah.

Jay: and sweeps the floors. No one thanks him at night, but if we come in and don’t see that, we’re like, “Hey, what happened to the cleaning crew last night?” You know?

Michael: And, I mean, that’s a goal of ours.

We were talking about that with our team today. Like, hey, we know we’re doing our jobs well if a company can focus on what they do and not have to worry about whether we did our jobs.

Jay: Mm-hmm.

Michael: Um,

Russ: Yep.

Michael: One more question I want your perspective on. Have either of you seen this arc before?

Like, there’s a new — oh, certainly — new technology, the new shiny thing, and you’ve seen some early adopters, and then people just jump into the ditch, and then it levels out. Do you feel like there’s another example of that, recently?

Russ: We’ve seen it — we’ve seen it with AI before, basically with precursors to AI. We saw it with middleware. We saw it with expert systems.

Jay: Yeah.

Russ: The rush to expert systems — “Oh, we’re going to take all the knowledge of everyone in your company and put it into an expert system, and you can stop worrying about this.

All the expertise is—” No, no, no. The architecture of your company and the architecture of your network is in people’s heads,

Jay: Correct.

Russ: not on paper. You can’t capture the connectivity that’s in someone’s head — you just can’t do it. You can capture parts of it, but not all of it. And we’ve seen it in the technology world as well, right?

ATM — I don’t know, the whole ATM boom and bust — and the dot-com bubble. We see this all the time, so, I don’t know…

Jay: No, I,

Russ: — there are plenty of other examples.

Jay: I agree, Russ. What about cloud? Remember

Russ: Oh,

Jay: — years ago? Dude, every session I went to, every marketing meeting with a vendor — it’s cloud, cloud, cloud. Now, you know, the cloud is just a thing.

It’s just a cloud, right? It’s a hybrid — there’s all kinds of variation there. But, man, everybody was like, “We’ve got to get to the cloud.

Get to the cloud.” And then they found out they couldn’t afford to be in the cloud. And so it’s just — it’s funny, you know — but that’s technology, right, Russ? That’s why guys like Russ, with all this wealth of knowledge and experience, have seen these ups and downs and these flows of technology.

It’s pretty exciting to see, and, hey, what we’ve got to do is just ride it, embrace it, and figure out how.

Michael: And I think it’s that discipline and understanding — yes. I feel like, if you can keep it in the front of your mind, that you’ve seen these patterns repeated, you can approach it with some discipline — and with that intelligent approach of understanding the benefits before you hand over the keys to the kingdom. But even then, you can try something, troubleshoot it, try to break it, see if it works, and then, once you get a solution that’s actually going to benefit the organization, roll it out — and still watch it, still monitor it.

Jay: Yes. But, Russ, where are you located? What state?

Russ: I’m in Tennessee — Eastern Tennessee. Yeah.

Jay: You know, eight or ten years ago, we’d never have had a podcast with a guy in Tennessee, recording live remotely, going out to listeners and viewers. Because, guess what — COVID happened, and Zoom and Teams and all that stuff blew up. The technology was there; we just weren’t using it. No one used it, right?

Michael: Mm-hmm.

Jay: But now we’re able to use these things. So I think it’s a great example of that. And, Russ, man, I’m excited about this episode, Michael. I think our listeners and viewers — I mean, I’d love to have you back on the show again.

Russ: Any time — just let me know.

Jay: Yeah, absolutely. Because I think you have a wealth of knowledge about a lot of things. It’ll be great for our listeners and viewers. This has been exciting, and I’ve gleaned a lot from it, Michael, and I know our listeners and viewers will too. And, man, we just appreciate you coming on today, as part of Clear Winds, and sharing your knowledge — thank you for that, for sure.

Russ: Sure, awesome. Well, thanks for having me on. It’s always fun to be the guest instead of the host.

Michael: Awesome.

Jay: Absolutely.

Michael: No, we definitely appreciate it. Is there any parting wisdom you’d like to share before we close out for the day?

Russ: Nope, I think we’ve said it all.

Jay: Yeah, awesome, awesome. Well, look, as always, on the IT Directors podcast — this is Jay and Michael with Clear Winds, and we are out.

Hey, thanks for joining us today on the IT Directors podcast. We’re so glad you joined us. Go follow us on all social media platforms — the IT Directors podcast, powered by Clear Winds. And if you want more information, check out our website, ClearWinds.net. We’re going to have show notes and special guest bios.

We’re going to have reels — our marketing team has done a fantastic job. Go check this out. We’re so thankful that you joined us today.

Where to Learn More about Russ White and AI Network Automation

That’s our conversation with Russ White — the first-ever CCDE-certified engineer — on AI, automation, and the future of network engineering. As Russ White puts it, the goal isn’t to avoid automation or AI — it’s to build the self-discipline to use these tools well, without losing the human judgment that keeps networks reliable. Thanks for tuning in to the IT Directors Podcast, powered by Clear Winds. If you enjoyed this episode with Russ White, be sure to follow The Hedge for more of his insights, and check out Clear Winds Technologies for for more information on how to optimize your business’s technology with (or without) AI.

More to explore