Inside NAF’s 2025 State of Network Automation Survey

Hello. Welcome wherever you are in the world. Good morning, good afternoon, good evening. As we wait here for everyone to get joined, please take a minute and give us an answer on the webinar poll that we have here today. It’s going to help us as we go along, give us some interesting things to talk about and see how our audience here today is aligning to topics we’re going to talk about. As we wait here, we do have a special guest here with me. I’ll let him say hi. For those of you joining early, you get to see who we’ve got here in the room with us today.

Hey everyone, I’m Scott Robohn. It’s great to be with you today Tim.

Absolutely, we’re going to have some fun here. We’ve got a special guest here on an NTC webinar, which is an unusual occurrence. It’s good to have Scott with me today and I’m just going to wait about a minute or so here for everyone to get joined in. It always takes a minute for everyone to get logged in as we’re going to go through the webinar. For those of you just joining, please do fill out that webinar poll that you see on your screen as you jump in. That’ll be great and we’ll have some interesting topics.

We’ll get the answers back on that later on in the webinar as we move through here today. Looks like we have pretty good attendance in here. Welcome in for everyone. Thanks for joining us today. We are going to be going through the State of Network Automation 2026. And what leaders need to know now. Basically breaking down the data from the largest industry survey on what’s working and what’s holding teams back.

This is from the 2025 State of Network Automation Survey that’s done by the folks over at the Network Automation Forum, specifically Chris Grundemann puts together this great webinar. I think this was the third one. That has been done, and we have really seen tremendous growth in the responses to this. As our industry in general has been increasing and growing, so that’s going to be our topic for today. For our agenda, we’re going to go through our intros for those of you that have just joined in here now.

Then we’ll take a look at that global network automation survey, then kind of compare that to the current state of automation, look at some organizational trends, along with some key operational takeaways, and of course, Q&A. A few things as we think about as we go through the webinar here today. Please do remember to use the Q&A box. That’s always the best way to ask us questions. That way, we can make sure we track them and get your answers back to you.

We may answer your question throughout the webinar if it’s appropriate to this slide. We’re on. If not, don’t worry, we’ll get to it at the end during Q&A. So please stick around for that as well. As well as do remember to use the emojis there those reactions. That’s really helpful for us to kind of see what you’re reacting to. We can see that on the screen here. So if you’re liking something, please give us a thumbs up or use those reactions. That’s down in the Zoom webinar bar there for you to use that.

And you will notice that the chat is disabled. Please do use the Q&A if you have questions for us. That’s the best way we can make sure we get you answered. So as always, my name is Tim Schreyack and I am the director of strategic transformation here at Network to Code and I’ll be your host here today through the webinar. But today, with me, I do have a special guest. As I mentioned earlier, I have Scott Robohn from Solutional.

Hey Tim, great to be with you and everyone on the webinar today. I am Scott Robohn. I am a principal and CEO in a consulting firm called Solutional. I have 35-plus years in the industry as an internet plumber and have really done some deep diving into network automation over the last three to four years. Also have the extreme honor and privilege of being a co-founder of the Network Automation Forum with Chris Grundemann. And I just want to buoy what Tim already said about this work that Chris has been doing.

We’ve seen the incredible response rate improve every year and the NAF community has actually played a role in getting the survey out to more and more people to get better and better results. And we’re going to talk about some of those results today.

Absolutely. And internet plumber I think that’s a new one. That’s a variant of a router jockey.

Sure.

Love it. And just a reminder for folks here, we always get this question. So I’ll just get it straight out here for you. The recording will absolutely be sent out via email after the webinar. So don’t worry, you’ll absolutely get a recording of it and that’ll be available to see later on. All right, so let’s get into it: the state of global network automation survey. We have more respondents, more diversity, broader data set as we look at the responses that came in this time.

And as we look through what we’re seeing now, we’re seeing a lot of folks really early in their journey. What we want to see here is kind of the difference between how that’s happening, how are we scaling, how are we moving across this journey as we go into operationalizing our automation. A couple things here, we just noticed and as we look at this survey here. This work has obviously been done really well by Chris.

But what we wanted to highlight here is as we review this survey, let’s look at it through the NTC lens and see how that compares to what we see in the industry and those corresponding data points there. So as we see what we have right now, we’re seeing a lot of growth in this survey in general. 681 participants, that’s six times higher than we’ve had in past years. And a 50% increase in the job roles, which is also really interesting. Meaning we’re reaching a broader set of folks across that.

We have very much a bottom up kind of respondent. That is 80% of the respondents are coming in as engineers and architects, whereas we’re getting about 20%, maybe 16% coming in at the leadership level. But that is also growing. So that’s of interest as well to us as we see that automation in general has been traditionally very grassroots. But now, what we’re seeing is leadership starting to pay attention. Any thoughts on that, Scott?

We’re pleased to see more leadership paying attention. I think that’s an absolutely necessary ingredient for any successful network automation rollout or program in any organization, whether you are a shop of five, a shop of fifty, or a shop of five hundred. I’ll say too Tim that the growth in the job roles has also been. One of the contributors is the network automation and network automation engineer taking more traction as an official job role. It’s interesting to see that settle in the industry as well.

Agreed. It’s no longer just a network engineer who happens to do some automation. It’s now truly a network automation engineer as the role, the title, and the focus of that role. So great to see as we expand out into the industry too. Totally agree. So where do we see people coming from? And this again is a major change. When we looked at the first surveys, we were seeing mostly U.S.-based respondents.

Now we’re really seeing a global response where, for the first time, the majority of respondents are not from the United States. While the U.S. itself is still making the biggest single country. If you look at it generally across the whole thing, we’re seeing a much broader representation. With the UK, Netherlands, Germany, and Australia rounding out those top four or five there. Definitely getting a much broader mix and this very closely reflects what we see at NTC.

We have a very similar mix across our client base. If you look at our client base that aligns very closely to these countries as well as really interestingly to the heat map that you see over on the right hand side of the screen. Our largest verticals are telecommunications, technology, financial services, and education. Very much in line with what we see there with government for us being also a pretty large bubble. So interesting there.

We’re seeing very similar alignment between what we do and what we’re getting here at the respondents. That’s good to see that we’re seeing something consistent as we look across both the survey and what we do at NTC.

There is a story that ties to this as well. After the first AutoCon event, we took it to Europe. We’ve been getting great response in the US and Europe, which is very consistent with those from the UK, Netherlands, Germany et cetera contributors there under the frequency chart. The thing that catches my attention in the bubble, the frequency bubble chart on the right is that largest bubble telecom. I come from a carrier background and have worked with telcos and carriers for lots of years.

And I see them definitely wrestle with rolling out network automation initiatives. And it’s of course, you can cite different issues in enterprise networks versus telco networks. I would love to hear more from the telco front. We do seem to get better representation from the telcos in Europe, largely because there are more of them due to national boundaries and PTTs sharing some of the more industrial strength. This network is for revenue production. How can automation help me guarantee those revenue streams?

That’s a thing I’d love to see more of in the future.

I couldn’t agree more. The telcos typically have very, very large networks, extremely complex with lots of nuances. Especially because a lot of them have come together through acquisition of other telcos, and that means they have just a hodgepodge of networks and equipment and different methods at which they operate them. So it’s definitely an interesting space. Something where we do a lot of work. We do work with a lot of telcos actually; that is a big vertical for us here.

I had one more comment on this slide, which was for those of you that are over in the EU, which is a big chunk of the folks here on the survey. Don’t forget about AutoCon coming up in June in Germany this year; that’s going to be super exciting. I am really looking forward to it along with NautoCon at AutoCon. Don’t forget about that. If you’re over in the EU and you want to join us, we’d love to see you there.

Tim, you couldn’t have teed that up better for us. Thank you so much.

You’re welcome. It is literally my favorite conference that I get to go to. A big part of my job is going to conferences, and this is by far and away the best one that we do in our verticals. So absolutely, I always love it to see folks there and get to talk to people. It’s really exciting to be at a booth at a conference where everybody that comes up to the booth literally knows who we are, or no one says, ‘Who is Network to Code? What do you do?’ Everybody knows who we are, so it’s a really fun conference.

I love it. How large are the organizations represented? So this box might take a minute for you to kind of wrap your head around what’s happening here. Basically, the size of the box is indicative of the number of headcount in that company or the size of the team. It gives you an idea of a representation here as we look at the boxes here and where we’re getting responses from. What this is telling us is that the company headcount is skewing large for folks responding to the survey.

We’re getting a lot of ten thousand plus type companies responding, and across the team headcount, it’s pretty steady. Somewhere in the twenty ish, maybe ten to twenty. That’s the typical size of the teams where we’re seeing. Of course, there is some big chunk below ten. A little bit about below ten and kind of a little bit above that. And we also see very similar alignment to this as well. It makes sense, what we do at Network to Code definitely aligns to the larger enterprise.

Where we have helping organizations that have just large scale problems. That’s what we’re seeing here represented in this graph as well.

If I try to move the Tetris blocks around a little bit myself, it looks like about 50% are twenty or fewer, or less than teams of less than twenty. And if you throw the 20 to 49 block in there, it looks like you are closer to 70% of the total population.

Absolutely. Definitely aligns. Generally speaking, from my experience in my career, teams are generally in that range, ten to fifteen people. That’s a pretty big network team when you think about it across your career. Absolutely. And now let’s get into what we found to be the most interesting thing. But before we do that, let’s just take a minute and take a peek at that webinar poll you all did, because what we really want to see is if the poll aligns to what we have here on the graph. And lo and behold, it does.

I love it. We have exactly almost that same curve, where if you rotate the webinar poll to the side, thinking you’ll be able to see that. We’ve got that very similar hill in the beginning coming up to around 30%. And then tailing off on that long slope down, exactly what we’re seeing before. Here on the chart we have in front of us that came out of this survey. One thing we didn’t get is anybody claiming up in that, let’s call it, 90 to 100%.

Which made me laugh when I saw that on the survey coming out of NAF here, we had a couple of people responding that they had 100% automated, which I really doubt. I am kind of curious about that a little bit. But really interesting to see here. We have exactly the same kind of responses coming here out of the folks here in the webinar as we did during the survey. So that’s also nice to see as well.

Even skewed a little bit more to the left, Tim. I think again, I am not sure I can do that transformation really well in real time, but yeah, which just leaves more room for opportunity to continue to drive network automation.

And so, if you are at the beginning of your network automation journey, don’t feel bad. You are not alone. That is the vast majority of folks at this point in time. You are in that early stage adoption. You probably have maybe some automation or maybe even none. You’re probably doing things, if you are doing any automation, it’s things like standalone Python or bash scripts, kind of sort of laptop driven type methodology. You don’t have a lot of transferability. It’s hard to share the automation that people create.

And it’s kind of experimental. Someone’s doing it on the side because it just makes their job a little easier, or you’re just kind of playing around with it. That’s generally what we’re seeing in the industry and in most folks here, just beginning, just getting your feet wet into this idea of network automation. Now as we move over to the next bucket, what we’re seeing here is we’re starting to move into the middle. Folks are beginning to start into this journey. We’re getting a little bit better.

We’re doing some automation. We’re probably starting to use tools, maybe not a full stack though. We’re just kind of starting to think about what that stack should look like. We’re beginning to expand the way of how do I actually get my team to be able to share into the things that I’m creating and starting to think of it from a strategy perspective. Hey, I actually need to have a team strategy, not just an individual strategy when it comes to creating automations now.

Scott, I don’t know if you had any other comments on this slide.

You can’t, you can’t, you cannot understate the need for strategy. This is a topic that’s been pretty impactful for me over the last six to nine months at AutoCon. There was a presentation; I can’t remember her name. It was in the leadership track where she basically said, ‘don’t just start somewhere,’ because that’s an oft-used ‘hey, just start somewhere; just start doing something’ with network automation. She built a very good case for you really should begin with the end in mind. What are you trying to do here?

Strategy and turning that into a plan for network automation really is a key marker of network automation maturity.

I would absolutely agree. And it’s one of the things that we commonly do, which is just to take some time to think about where we’re trying to go, what problems we’re trying to solve, and have a plan. If you just start doing stuff, you’re probably going to waste a lot of time and maybe even set yourself back because you might end up breaking something. Then everybody’s going to panic, and we’re all going to say we’re never going to do that again.

All of a sudden, now you’ve got to do a lot of retro trying to get everybody back on board. So better to come at it with a plan and not go down the wrong path first. Absolutely, I would agree. Then finally, at the very right end of the screen, we have the automation leaders. These are folks that are really moving into what we call the iterative stage. You have launched your foundation, you have your plan in place and now you’re just iterating on that automation. You’re constantly getting better.

You’re striving for that goal of full automation, which 1% of the respondents claimed they have. I would love to meet them because I really doubt it’s true. But if you are at AutoCon by chance, the person who was the one that responded that yes, you’re at 100%, please come up to the Network to Code booth and say hi to me because I want to talk to you. I want to hear about what your story is. How did you do that if you really did? I’m quite curious. Love to know about it.

It’s a bold claim, Tim.

I completely agree. Of course, this is the smallest group, less than 10% of respondents are up in this category here. So we’ve only got what 9%, total of 9% of folks are up in this box. So majority of folks are in the beginning in middle stages. So that’s kind of just like here’s what we see. Like and those are the obvious things that come out of this graph. I think if you look at it and start to group them.

But this next slide, what we really wanted to focus on is things that struck out at us here specifically at Network to Code because of what we do. And this is kind of how we saw this and what we see in our client base when we work with folks. And I think it’s really of interest because I think we can help to explain some of what happens as you take this journey. And how you might be able to make this transition yourself. What happens over here in this part right here? This very wild west.

As we said, we’re just kind of figuring things out. We’re experimenting. We’re doing some stuff. At some point, somebody creates some automations and you have some bash scripts or maybe they’re Ansible playbooks, something that they’re doing on their laptop. And you start to use it across the team. And what happens between this point here at this sort of early adopter and now moving into this middle stage, the key thing that you figure out most of the time is that I need a network source of truth.

I cannot continue with my automation journey if I don’t implement a network source of truth. On occasion, we have run into clients that are way up here in this box, and they somehow got here without doing a network source of truth. And it is a miracle that they did it right. This is what enables the rest of this journey, and usually, this is what explains this jump right here. This is the point where you are like, “I need to get a network source of truth, if I am going to be able to have good automation.”

I do. I agree with that comment. But one fun thing that we batted around in some of our prep for this was, in that wild west bucket. Let me just say, I think there is early internet history that encouraged these wild west behaviors of people who were building out the infrastructure in the nineties, in the aughts. If you remember the years of experience comment I made earlier, you know I lived through that. I’ve got some of this, the knuckle scars from installing stuff in racks at that time.

But it was keep up with getting connectivity out there. Great for getting stuff done but bad for. Sustainable shared responsibility across networking teams, and some of that behavior still persists today, as evidenced by the survey data. But there, I believe there is a little forward looking. The people who’ve got the IP addresses in the spreadsheet or in the notepad document, not a source of truth, but it’s like that’s the first sign that I need something more robust than a spreadsheet or just a notepad doc.

Sorry, I haven’t been a Microsoft user in a long time, but my Evernote note that has those addresses. That’s, there’s a you’ve got to get past that point to enable the rest of it, just like Tim said.

When Scott and I were prepping for this webinar, we were talking about it. Scott had mentioned using a spreadsheet as a network source of truth, and I rudely interrupted him immediately. I said that’s not a source of truth. He said, let me finish, and I said, but that’s not a network source of truth. The reason I hammered on that so hard is that we have so much pain and scars from this problem here in Network to Code. There’s even a client story I have, which was visiting a very large vendor.

We all learned their equipment. Let’s just leave it at that. We use their routers and switches every day, most likely. We were at that vendor and were with one of our mutual clients. A very, very large organization that literally had 30,000 or 40,000 switches in their network. So a good size network. And the vendor made this comment. They said, ‘Well, I don’t know why we keep talking about network source of truth.

You could just use a spreadsheet.’ And I looked at the vendor in the eye and I said, ‘That is the most ridiculous thing I have ever heard.’ They have fifty thousand switches. How are they going to use a spreadsheet to manage their inventory? That makes absolutely no sense. And that’s I think the key difference here, right? Is this idea of coming at it from kind of a vendor, sort of almost ivory tower perspective of like Nirvana land versus the real world, where I have a bunch of switches I got to manage.

And that’s just the key difference. And I think what happens as you come through this journey here, you realize oh that thing that I’ve always done, that spreadsheet I always used or I claimed I used, which I probably didn’t isn’t going to work anymore. Right? Something that’s scalable, something that helps me down this journey. So two things happen here in this middle. One is you’re laying the foundation, right? So you’re building out your automation platform.

You’re figuring out what that is, what it should be, and what should that tech stack look like. What tools do I want to buy? What tools do I want to use that are open source? How do I stitch those things together? Because the beauty of network engineering and network automation is that none of this is available off the shelf. You are going to have to build some kind of stack. And it’s going to be probably comprised of multiple components. Some of them are paid for, some of them are open source, most likely.

The other thing that’s happening during this is you are gradually learning what NetDevOps is. You may or may not realize that, but this is what’s happening. The key components of NetDevOps: one, a source of truth. I need to have a place where I describe what the network should look like external to the network itself, and I need an operational method in which I can actually implement those ideas. So that’s a key thing that’s happening here. You’re beginning to understand what NetDevOps is.

As you reach the end of it, what allows you to exit this middle bit here. I think of it kind of like the Gartner Hype Cycle. What allows folks to exit a particular hype cycle and move into production, just like the Gartner folks talk about it. We believe it’s this key pit right here. You finally understand the culture requirement. You move through this, you understand the technical requirements. I need a network source of truth. I need an automation platform.

I begin to learn what NetDevOps is, and then I am like, ‘I actually need to bring my people along with me.’ So if you are a manager here and you want to move your team through this phase and get into at least the upper one-third here, what you need to do is both understand the technology, but most importantly, understand the culture getting your team on board.

Getting the router jockeys to understand automation, to understand NetDevOps, and understand that it is critical to the future and how you’re going to manage your network and the changes that will be required as a result is what gets you into this full stack stage here. If you don’t do the culture piece, you’re probably never going to hit this full stack stage.

Just a couple comments on that. I don’t think it’s accidental that NetDevOps and culture are so close together and highly intertwined, to use a very technical term. I am one of those people that didn’t really like the term NetDevOps at first because I thought there was enough different about networking from DevOps, that let’s not use that term. I am over that. I am really, really good with NetDevOps because I think it’s ninety to 95% applicable to network operations today.

If you go back and you look at some of the things that are really inherent in the DevOps philosophy, it’s about creating culture. And reducing the distance between developers and operators, so it’s no surprise here that culture is very tightly tied to how I implement that culture through things like NetDevOps. And I’ll just end this rant with, culture matters, strategy and plan matter just as much as your tool selection. And you are moving through these phases here.

I’ve seen great leaders create incredible inclusive network automation programs in their organizations, and I’ve seen leaders that have really struggled with it through different client engagements. I am more convinced than ever the culture is supreme here.

And it is absolutely a difficult problem to solve. By no means are we saying this is an easy problem. You are going to have to put effort into it. It’s going to require both training, whether that’s formal or informal, along with really getting the team on board with the concept.

Especially as we look at our traditional routing and switching environments where we were very CLI or UI driven, this idea that the router or the switch is not the authoritative source for how it should be configured takes a minute to wrap your head around. It’s really a foreign concept to most of us in the networking space. The way that I always kind of try to explain this to our more traditional folks is, if you think of it this way.

The folks over on the system side have been doing DevOps for probably somewhere around thirty years now. If you log into any Linux server on the planet and you look at the dhcpd.conf file at the very top of it, it is going to say, if you make a change to this file, it will be overwritten by the automation. Because they have so embraced this idea that the authoritative source for how a device should be configured is not the device itself, it is absolutely the source of truth which is external to the device.

And that’s a key concept to DevOps. And that’s really what we take into NetDevOps is that idea. To Scott’s point, we don’t take really much else out of DevOps except for that concept. And that’s the idea we’re pushing here. It is no longer the switch that is accurate. What’s external to the switch is actually the authoritative source for how the switch should be configured. And here’s the catch: we can’t just do that willy nilly. It absolutely has to be done because we’ve got to keep the plane flying.

So we’re literally rebuilding the plane while it’s in the air. That’s the challenge we face as we transition from the wild west into automation platforms. How do we do that without crashing the whole thing to the ground? And that’s a key concept of transitioning into NetDevOps.

And Tim, you are so right. It’s a hard concept to get your head around as a trad network engineer living in the wild west. I know how to make this router sing and dance. I know how to get it working in the network, and I know how to keep it up. You page me at two in the morning, and I’ll be the hero and make sure it’s up and running. What do you mean you want someone to check my configs? What do you mean there is some other authoritative source of okay how something should be provisioned on this device?

It is a hard concept to get around when you grew up in the, hey, my job here is to just make it work. It takes more than that.

No, I think that’s actually a great point and something that we can look at as we think about how we explain this right here in the wild west. There’s a lot of hero culture, of I, we keep it running through blood, sweat and tears and duct tape. And we just brute human effort, right? That’s what gets it to keep it up and running.

And the goal of NetDevOps is that we get rid of, we don’t necessarily get rid of the hero culture, but we replace that culture with something that is more consistent, more reliable, more transferable, easier on all of us. No more waking up at two a.m. and coming in as the superman because something is wrong. We’re able to really just keep things more consistent and more reliable and make all of our lives better and easier, hopefully.

No weekend crash courses, et cetera, no seventy-two hour outages, those kinds of things where we’re just getting things going. I love the reference there, Scott. Absolutely. We spent a lot of time on that slide because that really is such a critical component as we look at the outcome of the webinar or the survey here. But now we want to move into the current state of automation where we are going along here. Please do fire questions at us as we’re working here. We’d love to chat with you, interact with you.

Please do put questions into the Q&A box so that we can definitely see what you’re thinking, what you’re reacting to. Do you agree with us? Even better, do you disagree? Tell us why. We’d love to hear from you. As far as your opinions out there and what’s going on. As we look at the current state of automation, kind of what’s being automated today? Uh, we see some interesting things here, And I just want to kind of like take a little zoom out and look across the industry.

Cause you’re going to notice right away that automation success is not evenly distributed. The safest, most repeatable tasks are the ones that are being automated first. That makes sense, right? The more complex and more risky ones, the slower adoption. So you look at the top here backups, right? Like I mean to be honest, We’ve probably automated this since ever since I was a network engineer. This was automated right? So this is nothing new here. That we’ve got going on.

Yeah, we’ve all automated backups because we needed it. You know, it’s our only hope of of bringing the network back when things go wrong. So yeah, we’ve absolutely done that and it’s easy easy to do as well. So that’s where we’ve got a lot of folks doing that. But then as you move down the list into things like deployments, upgrades, provisioning, This is where you start to see more partial automation teams making progress, but not really fully operationalized.

And then way down at the bottom here we’ve got things like troubleshooting. Traffic engineering network design, these are still pretty low because obviously they’re more complex, they have higher risk. The key takeaway being that automation isn’t random. It is inversely correlated to the complexity, and the risk is what we see here. You look at it’s fully automated versus partially automated. And then what are we automating down that stack? Did anything pop out to you? Scott, I’m just curious.

When you saw this, any thoughts?

So the traffic engineering one on the bottom right under fully automated is interesting to me. I have a lot of MPLS RSVP experience based on one of my vendor employers from a long time ago in a galaxy far, far away. And a lot of that stuff already works automatically; it’s protocol behavior that’s built in. Now I know there are things that carriers and service providers need to do in terms of maybe balancing flows across multiple LSPs.

And maybe that’s where the automation comes in on that, but that’s something that definitely stood out to me. The other thing that I think about a lot is firewall rules, and firewall rules grow one customer, one CIDR block at a time in some cases. And man, what an opportunity for offline refactoring of complex firewall filters. And ACLs, and being able to make it much more trouble, able to be troubleshot. Even maybe, take stress off your TCAM for that thousand line ACL that maybe could be done in ten lines.

And as you look across the line here, I was noticing firewall rules, both on the fully automated and the partially automated. They’re kind of right dead even with each other in both cases, which is of interest. Also, because this is one of the more complicated things to automate, it’s interesting where it falls in the mix. I am surprised it’s a surprise. Let’s see what we have here next as we look at those highly automated flows.

What’s interesting on these next slides is that automation is not random; it follows risk and complexity. Here we’re seeing backups operationally essential, which we just mentioned. Risk rating is quite low, complexity rating is also quite low. Make sense. Uses our familiar CLI workflow, something we’re commonly familiar with. So culturally, it’s an easy adoption. And the value is really high. So it kind of gives us that gateway into automating and gets us an idea of what automation can do.

So as we see here in the respondents, 61% fully automated, 19% partially automated. So between those two, we’ve got 80% folks are automated for their backups. I’m surprised, what are the 20% doing? You just hoping for the best. Apparently.

And this is not a hard problem aligned with your risk rating and complexity rating. There are tools that have been doing this for a very long time. I ran into a client that’s still using RANCID for example. Grabbing configs, not versioning necessarily and not maybe really structured, you know, containment of the backups. This problem has been solved for a long time. We’d love to see the fully automated proportion go up.

Absolutely. Now this should be, there’s no excuse. Let’s get this fully automated. This one is well mature technology, and there’s almost no risk. It’s virtually risk free. As we look at device deployments right now, this is where we’re starting to see relatively low risk rating but higher complexity. It gets harder and that’s somewhat intentional by our vendors don’t want this to be easy because they want to make sure that you use their ecosystem. And if this is easy, then maybe you might not use their ecosystem.

So our vendors do kind of make this a little bit harder and they kind of do it on purpose. So that is part of the challenge, right? That we have in the network stack specifically is just the complexity of automating our equipment and its deployment. That is only partially a vendor problem. The other thing is just our equipment is really different from the rest of the tech stack. If you think of your typical server, it’s got four interfaces, maybe six on the high end.

Like that might be a lot of interfaces for our server. Whereas your most basic network device has got forty eight ports. Forty eight interfaces. We just have a lot more complexity to configuration and deployment than say something else in the tech stack. So that’s part of it as well. A little bit of complexity of the hardware as well as vendors want to make sure that we stay buying their equipment, not some other vendor’s equipment.

This does drive some single vendor decisions for certain network roles, right? Because you think about specific functions, and I’ll just pick on BNG Broadband Network Gateway. There are a couple of popular vendors out there that support that. They have different models for how they implement it. Therefore, if I had a mixed vendor network for my BNG services, I’d have to accommodate the different models that the different vendors use.

So I can understand why that’s not fully automated, maybe not as high as we’d like to see it.

And Panagiotis, I see your question out there. I am really interested to answer that one. Don’t worry, we will get to you. I think that’s a great question. Hang on for those of you also, there fire questions at this, please. We’d love to answer them and see what you’re thinking. Starting to look into those partially automated flows here. As we look across that screen here. This getting to be a bit broader right things that are partially automated things like software upgrades. I could see right.

This relatively high risk and very complex, especially when we start to overlay business process. Because now typically around this, we have a lot of process I need to do my pre-checks. I need to do my post-checks. I need to get approvals. I need to make sure I do it in the right maintenance window. I need to do it in the right order. I got to do my secondary device before I do my primary device. You know, there’s just a whole lot of process that goes around that. So absolutely makes sense.

This is a bit more complex and has some more risk as well, right? Potentially we could cause an outage if we do this wrong. Uh, troubleshooting. You know, as we look down this path here, Uh it’s relatively complex and potentially has high risk. Because if you troubleshoot something come up with the wrong answer and take some automated response, you might do something incorrect. Uh so again high complexity high risk So, make sense as well here.

You know, if you are thinking about your journey, this is probably not where you want to start. This would not be a good starting point in your journey as you think about that service provisioning. Now, This one I find kind of interesting because I feel like this one is probably something that while it has a medium risk and medium complexity might have a lot of value. And.

The reason for that is because it’s so visible things that are visible to the outside business tend to get a lot of traction and can really help you drive your automation journey. That is, if teams outside of it are suddenly telling everyone, “Hey, the network team did this amazing thing. I no longer have to go get a VLAN port, you know, change by opening a ticket. I can now go to the self service portal, and I can get the, you know the port configured correctly is what I need through an automation.”

That really gets a lot of visibility in the organization, and that could actually get you that kind of publicity you need in order to be able to get funding or budgeting to say, hire NetDevOps network automation engineers, or you know, really to get the tooling you need. So sometimes. That kind of thing can be really of interest, not so much because it’s maybe low risk or low complexity, But more because it might just be really visible and folks might understand it and be able to, you know, show interest in that.

And, then of course, at the right end of the screen, there are config changes, right? Again getting pretty risky, pretty complex. Much harder to implement. And definitely again because of the vendor nuances. If you’re a single vendor environment, this might be relatively straightforward. If you’re a multi-vendor environment it’s going to add a lot of complexity.

I will say on all four of these categories, they all involve orchestration of multiple atomic automations. And I would say troubleshooting, service provisioning and config changes cover very broad categories. Many different things can fit into those buckets. If we just pick on software upgrades for a bit, this is one of the most well understood sets of behaviors that we’ve had. Everybody’s had to upgrade routers and switches and firewalls. However long you’ve been doing this, this is one thing that you’ve done.

And you can break the workflow down into six, seven, eight steps that need to be done. Do a pre-check, like what are my BGP connections? What does my OSPF or IS-IS state look like? What does my routing table look like? Capture that. Preload the new code on the box and then do the MD5 checksum to make sure it wasn’t corrupted in the transfer. Then drain the traffic off. Then do the upgrade. Then drain the traffic back on.

Then bring everything back up and check your post-checks and do the compare of pre-check and post-check. This is not rocket science and I mentioned that intentionally because of Artemis II yesterday and today. So much of the work here is the non fun, the non exciting. I really need to understand the workflow and how it strings together. And that takes work. But once you’ve done the work and you have a pretty good capture of these are all the things that need to happen.

Here are the error conditions that I can expect, then I won’t ever need to worry about it again. Hardly ever. So sorry for the rant Tim.

You’re good. And I just want to take one quick minute because Scott mentioned something I think that’s really important to understand. If you are new to network automation, this is sometimes a confusing point. Which is when we say network automation, we use the word automation generally speaking across the industry. And when we say that what we actually mean is orchestration. We confuse these terms. Automation, as Scott referred to them, atomic automations is really a very specific task that we use code to execute.

Orchestration is how we stitch those automations together into a workflow to actually accomplish a task. So when we commonly say network automation, what we really mean is network orchestration. But it’s just something we do in the industry. You may be confused by that when you first get in there. Like people are talking about automation, they’re talking about orchestration. What’s the difference? Well there you go. Orchestration is simply stitching together a bunch of automations into an overall workflow.

Generally speaking in the industry, we call that network automation. I don’t know why it’s what we decided to do. So here we are. Um, But let’s keep moving on as we get through the rest of these charts here. And, we look at kind of again, aligning to what we saw in the early stages of their the survey. And then what that means here across the uh, the rest of what that actually implements too. So if you look here first, like 82% using homebrew scripts written in house, 73% using open source.

Those folks probably very much overlap that Venn diagram is overlapping heavily with that beginning part of the chart. Uh, as you move through your journey and you get into the middle, you might still be using open source apps, But you suddenly realize I need support because this thing is becoming critical to running my business. It’s no longer the wild west. I’m now treating it like a real enterprise app. And, that’s also probably when you start to see some proprietary commercial apps coming into the mix.

So beginning early days likely a lot of homebrew, a lot of open source without support. As you move into the middle, you start to use support and you start to use commercial apps most likely. Generally speaking, across the mix there. We noticed some of the popular tools. Both what we see here from the Network to Code side Ansible, NetBox, Nautobot of course here at NTC. Popular paid tools: Ansible Automation Platform.

Absolutely by far and away number one, most common thing that we see in all virtually all of our clients absolutely using. And then of course the Cisco products as well. And then same with popular languages. Python number one hands down everybody’s using Python, 50% of you using Go. Interesting. I am glad you dove in that pool, but I don’t know why you did. Any comments you have here? Scott.

I have a friend, a gentleman who used to work for me who’s now at Google. And he’s very much involved in driving Go adoption. So it’s something to be on the lookout for. There is a usual suspect that’s missing from the list, right? And it’s Perl, right? And there is still a lot of production Perl scripts out there. And you know, do you touch them if they work? Maybe not. But maybe you take a look at, what’s a rational upgrade strategy for that legacy technology.

We do run into quite a bit of Perl. In fact, a lot of clients actually come to Network to Code, asking us to upgrade their Perl to a Python base. Because someone left, they had a Perl guy or girl and they left. Now we have a problem. That’s a common thing that we do. Organizational trends, success in automation is not just technical. It’s absolutely organizational, as we were referring to earlier. This is really key, who’s building the automations right now. We’re looking at network engineers with automation skills.

And then following up closely now. And growing is this software developer engineers, and this is absolutely a trend we’re seeing, and why I paused to hold on Panagiotis your question. Like you said, I changed my job from a network engineer to a DevOps engineer in order to learn the principles and I want to write code, et cetera. I don’t want to touch the network anymore. I just want to automate systems. Do you consider that the right choice? I would say yes.

If only because about fifteen years ago, that was the choice I made, and I thought it was like everybody was going to follow me. And then all of a sudden, no here. We are fifteen years later, we’re still talking about it. But no, I believe this is absolutely the trend as we look forward. Which we will see more and more software driven, more automation driven networking and less of that old school CLI driven.

I don’t know if you had any comments there Scott, but that’s definitely what I think is the future as we look at this.

I am out there as an advocate for learning the DevOps and CI/CD associated processes and tooling. For network management purposes, I think it’s time whether you do a lot of work on CPE, on premises gear that is under your control, or you do things that have significant abstraction layers. And you can do it programmatically. Adding those skills on for your traditional network engineering skills is definitely the right move.

And I think if you look here, what we’re going to see as well is developers and SREs being paired with a network engineer. We’re going to have co-working, where you have two individuals who are each well trained in their vertical and then working together as we move across here. That’s my suspicion of what we’ll see here, at least in the transition phase right as we transition into fully automated networks, which eventually we will land at.

On the pairing concept, I’ve had a couple of really good interviews on the Total Network Operations podcast that take that model explicitly. You’ve got network people that have those network engineering skills, and you’ve got software dev people that understand more of the automation and build process. And it’s great cross training for both groups of people.

Not everybody’s going to become as equally proficient in both areas, but one friend of mine in my conversation with him said, when they first brought the team together, all they did was stare at each other suspiciously from across the room. And part of his role as a leader was to find ways to bring them together and help them figure out what the best ways for them to collaborate were. It was a really great story.

Yeah, no cause sometimes I think, especially in the early days. On one side, we might be like, are you going to take my job? And I think the answer is no. Automation isn’t going to take your job, but somebody who writes automation will take your job. So that’s absolutely the future that we see as we move forward here. Where survey respondents’ skills land right. So we’re seeing here a lot of folks with a high skill on the networking side and less on the developing side.

So as expected, we’re gaining these skills in our industry. So if you’re thinking, how do I begin to move into this field? How where should I learn? What should I be studying? Absolutely, Python and Ansible. Those would be the top two that we would recommend from our experience here. Those are the things that are going to get you started into network automation and the tools that you would need.

That basic tool set of where do I begin, how do I start, how do I make sure that I can be on the train as the network automation journey moves forward.

One of the things to note on that last slide, it took me a minute to process it. But you’ll notice, like I am sorry, I can’t remember. Is it OK to go back one, Tim?

I will absolutely go back.

So your level of network automation knowledge, you might say, the bars are the same size compared to your networking knowledge. Just look at the axis on the left there; they’re different axes. If I think you adjusted to the same y-axis, you would see the bars on the right-hand side go lower, which jives with what we’ve just said about our level of network automation knowledge not being as high as our level of networking knowledge.

Good point. The legends there do make that a little bit tricky when you first glance at it. That point exactly.

Sorry, not trying to troubleshoot in real time, just in case anybody was confused by it. So yeah

You’re good. All right, so how is this affecting the job market? What we’re seeing is that organizations are training existing teams because they’re unfamiliar, expanding their headcount and bringing in where necessary, and then partnering with outside vendors when all else fails. So basically, organizations aren’t just letting people go. Engineers are modernizing their skill sets, and that is likely the path that would lead to good success as you move forward.

And also of interest is that the majority of the responses are aimed at acquiring the right skill set either through upleveling or hiring those that already have those NetDevOps skills. Some challenges maybe kind of what’s holding organizations back. Often responding that hey, it’s because the most visible, but the operating model and culture are typically the real impediments. Again, that culture problem right? Like if we can’t get over that culture hurdle, that’s going to hold us back.

And we found that navigating this absolutely can be solved with the right training. Whether that’s corporate training from a company like NTC or internal training, or in fact, maybe sending people to conferences and getting them signed up for the right classes at those conferences, but we really need this leadership buy in.

So if you’re in leadership here in the seminar today, we definitely want you to understand the value of getting your teams on board and how critical a role you play in this transition because it isn’t just technical. It is actually mostly about the organizational transformation that’s really what enables this journey. How are we being measured now? This is one I want to spend a second on because I have a couple of points here to make.

As we look in the early journey, you’ll see commonly no formal measurement in place. That’s that wild west. That’s where we’re just kind of doing stuff or figuring things out. We move into that middle phase and then all of a sudden, we think the way to do this measurement is by time. We’re going to measure by time, and that’s how we’re going to show our value back. I understand that’s kind of like the easy go-to, that’s the easy thing to measure. We can say, hey, this automation saved X time.

The problem is, that is not the real goal. The real goal is the operational stuff: the quality metrics, the reliability, the scalability. These things are not necessarily related to time. So I understand time is the easy one. That’s the one you might go to first, but that’s not the important one. Don’t focus on that. Don’t focus on saving time. Focus on your operational metrics, your quality metrics, your scalability metrics. Those are things that matter. Those are things that you should be pushing forward with.

Those are things you should be promoting to your leadership. And if you are a leader to the executives, like that’s the stuff that shines. That’s the stuff that will get you more budget. That’s the stuff that will show value to the business, not time saved. That’s my little soapbox. Scott, do you have any comments there?

I will compliment or maybe just view it a little differently. Time saved is important, but it’s not of primary importance. And you need to have a fuller set of metrics. I would say don’t rely on time saved as your only or even primary metric. Look at scalability. Look at what helps drive assurance and reduces error. What lets me do something a hundred times a day now, instead of just three times, because I had a human do it?

You need to take that holistic view of how you are measuring any network automation rollout or program that you are working on.

I would agree. Now what about AI? Because you cannot have a webinar in 2026 and not say the words AI. And we even got a question about it, so here we go. This is what we’re seeing from the survey. Really nobody has any current plans or initiatives pretty much. There’s a few folks that are maybe trying some things out. What we see here at the Network to Code perspective.

What we’re imagining and visioning is that AI at the moment is very good at finding that little funny thing, that needle in the haystack, that weird thing happening in your logs. Maybe that little blip. AI is really good at picking that out. What I don’t want AI doing is going out and making a change on switch. Because currently, at least today, AI is not going to give you a consistent, repeatable result. So what does make sense though is building automations that are codified.

I have a thing that I know is going to have a reliable result and maybe some AI response triggers that automation. That might make sense. But the idea of AI going and changing my switch, I don’t want that today, probably not for quite a while. That would be here at NTC. That would be our take. Scott, I am curious if you have a similar take or any other thoughts there.

So on the one hand, it’s a really exciting time to see what the art of the possible is going to be here. That being said, I don’t roll anything out into production until I’ve tested it thoroughly. I know what the outputs are going to look like. I know what repeatability looks like and so forth. I am just going to take you back to workflow. However, you want to automate a workflow or orchestrate a workflow.

You are going to make sure that you do the work of defining it, understanding the constituent steps, and understanding the mechanisms that I am going to use to do that automation. I would encourage people to play with how AI-based tooling can help you with this. You want to have confidence in it before you roll it out in your network. Again, of course, it’s a different technology and it is something new. But the old rules still apply. I don’t want to make things worse in my network.

I want to make sure I know what behaviors to expect before I roll it out.

Absolutely. A quick one here from the NTC perspective, we do of course have NautobotGPT. That is a way to interact with Nautobot, get information, get reports, find information that is harder to do, and have that natural language conversation with the AI and in turn get that data back from Nautobot. So that’s a great solution as well. As you think about how to use AI, that might be a way. It’s a read only mode, so it’s not going to go off and make some change out onto your network. We just have a few minutes left.

So we’re going to move into that Q&A session here and see what questions of interest we’ve got. Let’s see if any are popping out at you. Scott, please feel free to speak up. If not, I will take. Let’s see we answered the AI one. So next one was, actually this is kind of interesting. I think software upgrades, not rocket science, but high impact and vast blast radius. This is the thing we hear a lot about automation. It’s got this huge blast radius.

I don’t know if I really want to do that because it’s going to be faster. But what happens when it breaks? You have any comments on that Scott?

Sure. You are absolutely right Ajit. The blast radius matters and don’t treat our very brief discussion of it as comprehensive. You do need to have a design that accounts for high availability and redundancy. Within that construct, your automations and orchestrations should plan for maybe I have a pair of devices in a role for high availability. My orchestrations should very much account for the operational health of the live device while I am upgrading the device under service and vice versa.

So yes, you absolutely have to account for things like that. You’re spot on.

And actually, Mike here has a follow up one that I think is quite of interest to talk about. He mentions, hey, I’m wondering about vendor platforms that you say hey, software upgrades are not rocket science. Cisco IOS XR, for example, it’s multi file multi step, whereas XE that’s easy. And I think this is exactly the point where automation is really good at handling things that are multi step, that are well defined. Upgrading an IOS XR device is well defined.

There are a lot of steps and you have to do multiple things, but it is a very well defined set of tasks. There isn’t a large if then else structure under that flow. That’s a prime candidate for automation because now it takes that very difficult thing for a human to do, codifies it and makes it super easy and super repeatable. Hit the button, done. No worrying about did I do this? Did I forget to do that, etc.

And right along with that, even for those multi-step upgrades, depending on what version you’re going to and from, sometimes there’s multi-step upgrades you need to manage too. Let’s make error handling great again. If you can go through the steps, you can identify what are the possible errors that I can get and I have to gracefully handle those errors and know when to abort an upgrade because something went wrong. Again, if there are steps that can be identified as part of a workflow, you can automate them.

One question here about a small network. I think he mentions having less than ten devices to manage, and what could I do? You are absolutely right at that scale. Automation is going to be difficult to prove its value because simply automation starts to have value at larger scale. That is absolutely true. So that is going to be a challenge and something you have to look at. What is your expected growth? Are you expecting to grow into the hundreds at least for your practice?

The good news is, it’s going to be very easy to get your source of truth up to date, get it accurate. You can learn skills, you can do all of those things. So absolutely great place to start. But is it going to be you’re going to go get a bunch of budget for deploying some expensive product? Probably not. But that doesn’t mean that you can’t get started and do things like a good network source of truth. Absolutely. We have one minute left. I think we have time for maybe one more question.

Any gains maybe as an early win by taking current state of the network and translating that into a network source of truth? So basically, how could I get that current state into my network source of truth? The classic problem of how do I device on board. Absolutely, there are a lot of solutions out there. Some free, some paid. The number one thing is you’re not going to do this by hand. You absolutely want to do this by code, assuming you have any kind of scale. You know thousand plus devices on your network.

That would be I say the number one takeaway, you’re going to absolutely want to find out how to do that by code, not through any hand methodologies. We are at time unfortunately. Thank you for all the questions that you’ve been firing at us here at the end. We will get the rest of you answers, don’t worry, we won’t forget about you. But just a real quick recap what we went over today.

We looked at that state of the network automation survey, the current state, our organizational trends and those key operational takeaways. Don’t forget if you had some questions please fire them at us, we will get you answers. Thank you as always for joining us, and here are links to all things Nautobot. You should see them in the webinar chat as well as here on the screen for you. Thanks very much for joining us. Happy automating, and look forward to seeing you on the next webinar.