Network Automation as a Business Culture: Why the Whole Company Has to Evolve

The business benefits of network automation are sometimes lost in discussion around network automation technology. Cause we nerds, we, we do love to talk nuts and bolts because, Hey, this automation stuff is pretty cool. Our guest today is Tim Fiola and Tim believes that the technology aspect of network automation is more or less a solved problem. We can argue with Tim about that, but that's not the point of the show today. From Tim's perspective, the bigger issue now is to engage the business at a cultural level so that network automation is properly embraced up and down the management stack. Tim joins us to discuss these ideas in more detail based on a blog post he wrote on a Network to Code and we'll link to that in the show notes. Tim, Hey, welcome back to Heavy Networking. It's good to have you back for this discussion. And Tim, if we just want to springboard into some of what your blog post covered, you make the point in there that network automation is, is a journey. It doesn't happen all at once. And you're not just talking about technology, are you, Tim?

Absolutely not, Ethan. First of all, it's a pleasure to be here. Thank you for having me. And thank you everyone for listening. But yeah, to your point, Ethan, absolutely. The automation, network automation is indeed a journey. It is not, it is an evolution, not revolutions. I mean, revolutions are messy and they're terrible and no one knows what's going on, but an evolution is a bit more controlled. and a bit more, well, evolutionary, if you want to put it that way. both in the technology and in the culture. On the technology side, you know, you have an evolution where you start with small tasks. You start to abstract away your small tasks by, for instance, you know, creating a script to provision VLANs or something like that. That is a great abstraction tool. But then as you get into starting to automate workflows, your technology starts to evolve along with your needs and what you can do. Alongside of that, there's a cultural evolution, which doesn't get a whole lot of attention by management or by engineers, unless it's explicitly… brought up as something to address.

So in your post you mentioned there's the IT cultural evolution, which has gotten a good bit of press. We've talked about it on podcasts. There's been plenty of articles written about the IT culture, but you're also emphasizing that it's not merely the IT culture that changes, but also business culture too.

Yeah, the business has to adapt to what's going on in IT. And that adaptation ranges from educating management or making sure at least management understands why you're automating and the value that gets returned to the business. And you can also look at HR. HR has to understand that their network engineers are going to have a different skill set. They need to go out and find a different skill set. Not only that– With a different skill set comes different expectations for salary and things like that. So it's not just what happens in IT that supports and maintains the automation evolution. It is what's happening in the entire company that allows it to move forward.

So what, okay, so I've worked in lots of IT orgs over the years and what the business wants to know about the guts of what's happening in the IT department kind of varies. Some shops, they're pretty technology oriented. And so what's happening in IT matters to them because that is the platform upon which they deliver the business. And so they, they care a bit more and maybe some of the leaders there. technology oriented and they've got some background there. Other shops. IT is the snot of the business. Everyone has it. You've got to cope with it, but it's not pleasant. And it's looked at more like a cost center. They kind of don't want to know the details. So you're arguing that business and business stakeholders, when it comes to something that from a business perspective could be looked at, oh, so IT is delivering, in this case, how they do the network service delivery. I don't care if they're automating, what's the difference to me? You're arguing that they really need to care about the evolution as it's ongoing.

Yeah, your business is going to have to evolve in many ways to keep up with the demands that your customers are putting on you. One of those ways is automating, or at least I'll say this, executing workflows quicker. And IT is a huge part of that. If you don't– If you don't care what's going on in IT, you do so at your own peril because there's important work going on in IT. And it's work that can deliver value back to the business as far as the value it returns to its customers and the revenue it generates, among other things. So you can't ignore it. And if you think to yourself, can we really ignore what's going on in IT? Given that IT is oftentimes the basis of a business's technology, if you ignore what's going on in IT, you're ignoring all the advantages that can be derived from implementing automation to give value to your customers quicker.

Absolutely. That is the business. If it does not understand on a deeper level, put more interest in what's happening in IT on a deeper level, they are potentially overlooking a business advantage. And it behooves them if they're trying to be profitable and make more money and service their customers better to pay deep attention to what's going on within IT.

Yeah, absolutely. Absolutely. And when we when we look at the culture side of it, you know, if you're in management, you could easily be forgiven for not understanding that culture is a huge component of this, probably the most important component in the long run, because if you search for network automation on Google or anywhere else. you won't see any mention of culture, at least not in the first, I don't know, I looked through five pages, didn't see one mention of culture, but it's culture that actually makes it possible in the long run. And we'll talk about how that is today. So you could easily be forgiven as a manager thinking, okay, we'll go ahead and train our managers in Python and Ansible, we'll automate a few workflows, and then we're automated, it's great. We've done our work as management. Your work is just beginning at that point because there is an organizational transformation that has to happen to give this. evolution the the capability to to keep moving forward

Okay, we, we got to dive into some of these things cause there's a lot of angles we could take on where the lines are drawn between what management cares about and you know, what they're enabling and so on. But there's another aspect of this. We've got to pick apart first, Tim, in your blog post on the Network to Code blog. You mentioned the technology part of an automated infrastructure is a solved problem. We have the technology. So I could argue, sort of in the sense that, well, in fact, what you, you guys do at Network to Code is helping to make sense of the bazillion tools that are out there and all the different approaches that one could take to automation and the difficulty of. of automating in that it's. It's a solved problem, but it's still incredibly hard to deliver. So how do you mean for the context of that conversation that the technology part of an automated infrastructure is a solved problem?

Sure. You know, if you were trying to automate your network, you know, let's say even just 10 years ago, 12 years ago, you'd run into a few different obstacles. You know, how do we how do we abstract away these device details? How do we authenticate with our devices? How do we orchestrate our different tasks? You know, what data format should we use all this stuff? And 10 or 12 years ago, we would have ended up with trying to do that. Probably a bespoke. automated system with a lot of dependencies and so on, bespoke very custom to our environments and probably not even attempted unless we were a very large organization that had to have something like a service provider, let's say. Yeah, absolutely. And now we have a wealth of tools here for we can authenticate with devices. That's easy now. We have plenty of orchestration platforms to choose from. Nornir Ansible, Rundeck, SaltStack, whatever, coding. Python is now pervasive. Ansible is now pervasive. We have standardized JSON data formats such as– JSON and YAML and even XML still being used, awesome. And we also now a huge component of this, we have the collective experience to use them. And what I mean by that is we have a lot of experts now that know how to use them. Additionally, engineers or whomever can go online and get tutorials and YouTube videos and– end up on Stack Exchange, which I always do, to find the answers to your questions. That's all there now. So it's much more accessible. You know, and another way to, you know, and I know some people will, there's probably some according to cases with technology where it's not a solved problem. Great. Go on the internet and complain. But I would argue this, if your automation effort fails– It's probably not going to be because of lack of technology or lack of how to use the technology. That won't be the reason your automation effort fails. I would argue it's most likely going to be an organizational failure. to address the culture that you need to foster to enable that automation to move forward.

I think that's all fair. I get what you're saying there. A lot of people have put a lot of efforts into abstraction layers for one thing, just being able to interact with a variety of devices in a somewhat standardized way because there's abstraction layers underneath that are enabling some level of standardization and then a variety of tools. So I, I kept where you're coming from there. It doesn't mean the task is easy, that it's a solved problem in that sense. –

Right, it's not easy, but it's solvable. We've done it before. –

Okay, and so in that context then, we're gonna leave the technology part of the conversation behind and go back to the culture then and why the business would care about these things. So what, let's drill back into something we were talking about a little earlier, Tim. How much does the business need to understand? about, well, we're focused on network automation in this conversation. How much does the business really need to understand about that so that the business is properly supporting a culture of network automation within IT?

Right. The big expectation that people need to understand is that the amount of people required to run a network is changing. because we're moving towards automation. And that means the amount of people required to do the networking tasks is changing. And, you know, I'd argue it's probably going down because an automated infrastructure amplifies each person's productivity. So you have the amount of people is changing to run a network and also their skill set is changing. This, sorry, their skill set is changing since they have a more adaptable skill set. you need less people because the skill set involves necessarily making everyone else more productive through automation. So the business has to understand that. –

Well, there's people that are listening here that are like, wait a minute, wait a minute, Tim, does network automation mean I'm going to lose my job? So are you saying that from a business perspective, we talk about a reduction of head count or does that mean we can do, we can grow the network without necessarily having to add head count?

Yeah, I will argue this. Automation allows less people to do more work for certain. But what I will also argue is that there's some work, there's some amount of scale, some amount of tasks, some amount of velocity that is impossible to achieve without automation. Meaning if you want to improve your velocity of your processes or the amount of work that can be done, You can't anymore just throw more people at the problem and more money at the problem because people get in each other. People get in each other's way. And there's only a certain amount of money you can fund for a certain amount of people. So you're going to hit resource constraints. I would argue I would put forth that. The automated infrastructure doesn't, I don't think, reduce its head count so much as it enables people to do more and to break beyond the bounds of what's possible with just people doing manual tasks.

Now you categorize that as changing skill sets. And we are talking about. really a growing skill set. So it's not as if a network engineer doesn't need to know network fundamentals anymore. In fact, they need to know them ever more deeply to facilitate an automation platform. The changing skillset is in, now you're not walking into the command line or using a GUI to manipulate network configurations and change network architecture. You're using an automation platform and the skillset is… Now they've got to understand how to use those tools to facilitate automation and then maintain that platform.

Yeah, you have to understand how to use the platform and also how to maintain and expand the platform's capabilities. So that means, you know, most likely Python or probably increasingly Go, Ansible, Jinja templating, huge part of it. You need to understand what a Jinja template is and how to leverage it. Those are a few examples of the skill sets that are needed. But those skill sets are amplifiers. And I do think there's always going to be a place for the pure network engineer. I mean, there's some network engineers you meet where, you know, within a few minutes of talking to them, you know, wow, you are a strategic asset, Mr. Network engineer. You are awesome. Keep doing what you're doing. For the rest of us, me included, I chose to learn automation so I can allow the pure network engineer to execute high value tasks. And also I can expand my skillset, expand my value to the organization by learning automation. by freeing myself up from having to parse data endlessly simply because I understand the context around the data. That network engineer should not be doing that. So You know, I would argue that it's… Sorry, I lost my train of thought there, Ethan. Anyway, I would argue that you'll always have the place for a pure network engineer, but for the rest of us, we need to expand the skill set and enable ourselves and the pure network engineer to keep working on high value tasks. High value being network engineering or network automation engineering. Get out of the trenches for OS upgrades. Get out of the trenches for manually parsing data. Stop. Stop its madness.

So then from a business perspective, looking to hire and fill the, these different skillsets. I think I heard you say there is a role for a pure network engineer. There's also a role that would be distinct for someone who is an expert in automation and automation tooling, such as you've mentioned Python Ansible and things that work with Python like Jinja templates and so on.

Yeah, I think preferably it would be a hybrid, someone who's got network engineering and automation experience. Because being on that cusp between the two worlds, between automation and engineering, that is a high value place to be. That's a really high value place to be. If you can act as a translator– between two skill sets that are not necessarily easily understood within the other skill set, you can add a lot of value in that role.

Okay, back to that business stakeholder then it's thinking about this, thinking about positions, how to describe the positions and the skillsets required. What is the business justification for this or put another way, what, what are the business goals that they're meeting when they find these automation capable humans and bring them on board?

Well, you want to make sure they understand the benefits, meaning they're not just buying more toys for the engineers. These are tools to allow the people you're hiring to actually go forth and do their jobs and do them better than they could under a manual regime. First of all, it's not just more toys for the engineers. This is a business benefit, a competitive benefit for your business. –

Well, you said something really, really important there when you say not just more toys for the engineers, because when you're talking about more toys, that's a CapEx or an OpEx. It's, oh, you need a tool to do the thing and that helps me in this way? Great. It's a very straightforward exchange of some kind of capital for some kind of a benefit and off you go. That's a kind of a… a time saver, if you will, but this is more. This is more involved than that. This goes more deep.

Yeah, this is not just tools that perform tasks. This is an infrastructure that performs workflows. And the business in the end really cares about workflows. Why? Because the workflows deliver value. That's why the business created the workflow. They either deliver value or revenue, sometimes both. But the point is the business wants to generate as much value as they can. So you need to understand that by automating workflows, you can one, deliver value sooner. And since automation allows less friction. for the workflows, you can typically execute more workflows in the same amount of time. So there's a kind of a double– amplification there. that automation allows. –

Dude, you realize you're talking about something that we're bridging a divide here for a large number of organizations where they have always kept IT kind of in the massive technology silo over here. The IT people do this and when I can't get my webpage to load or my email isn't working, I call them, I call into the silo and say, "Hey, this is broken and I complain," and then they fix it. You're talking about something that is such going to be such a shift for many orgs. Many orgs get this. They're technology centric, but many organizations do not. And they almost compete with IT. And so to think about. their workflows from a business perspective, thinking about it's processes and workflows and enabling workflows and thinking about them from that business perspective is. Well, maybe we're talking about IT as automation, as an evolution, but maybe this is the revolutionary component, Tim.

Well, it's a revolution, I'd say, in the thought process of management. It is still an evolution on the tactical scale in that implementing an automated infrastructure is not just a switch you flip, but you're right in that the way of thinking with management has to change in order to– unleash these benefits and maintain the benefits of an automated infrastructure. It's not just a train your people, automate a few things, and then we're good, we've done it. It is not that at all. –

But still, business stakeholders and execs tend not to be deep technology experts. And a lot of the, we very quickly can descend into domain specific language around networking and network automation. How do we explain to the business folks what this value is here so that they're thinking about it in these terms we want them to think about?

Yeah, so automation really aligns with a lot of really typical corporate strategic objectives. Cash flow is one I call out in the blog post. When we talk about automated workflows, why do we do that? Well, because we want to get more value, more revenue quicker. up. Automation allows that. Automating workflows allows that. Also, if you look at it from a business perspective, you're preserving your institutional knowledge when you implement an automated infrastructure. Meaning, people leave jobs all the time. It happens everywhere all the time, every day. So the goal of the business, one of the goals of the business is often– When someone walks out, we can't just afford to lose all their knowledge that that makes our environment unstable. In an automated infrastructure, that person has contributed to your infrastructure, putting their best ideas into that infrastructure. So when the person leaves, yes, it might be a blow, but they've left behind some of the best parts of them in that automated infrastructure. So you can continue to continue the business running smoothly, both tactically and even maybe strategically because you have this infrastructure that lets you keep going. –

Okay, we got to dive into that point a bit. So the first point you made there was about cashflow. That's straightforward enough businesses understand cashflow and if we're enabling greater cashflow or… a shorter close to the sales cycle or something like that tied to network automation. Hey, you get better cashflow. That's easy to understand, but this preserving institutional knowledge may not be so obvious. Wait a minute. You're telling me as a business stakeholder that changing the way I am ultimately provisioning my network preserves institutional knowledge. That's not immediately obvious perhaps.

Yeah, it might not be, which is why I wanted to stress that because we've all been there in the places where a colleague has left, hopefully for greener pastures. And then we're like, well, what are we going to do now? an automated infrastructure helps solve that problem as to what we're going to do now. Well, we're going to continue doing what we did yesterday when the person was still here because we can. That person has left a lot of great knowledge. in our automated infrastructure. Therefore we can run smoother. We're not as disrupted when a person leaves. So absolutely it makes a difference there. –

So I'll put something around this just myself coming from lots of engineering background. before the days of automation and ye olden days, Tim, when, you know, I'd be provisioned. I don't know what it is. You know, the classic example of it's a new VLAN. I knew what switches to hit and whether a VPN tunnel might need to be updated to cope with the new address space that was provisioned. And I'd have to touch the DHCP server and you know, and so on. There's a lot of moving pieces and parts there. I knew how to do that if I was a good boy. I had documented that process so that someone else could follow it, but you know how documentation goes. It's a manual process and the documentation falls behind and so on. Okay, well, what if this was a modern implementation of that process and it was automated? then whoever comes behind me doesn't have to read my documentation and hope it's up to date and hope they have access to all the things and that they can kind of get through the process. The automated workflow has already been built and we'll do it with a low error rate and all the rest. Meaning as you were putting it Tim, we can just kind of keep on going and get work done even though that person had left the organization.

Yeah, I mean, first of all, does it does anyone ever read documentation? I mean, no one wants to. We know that. I mean, it's just like, oh, my God, you have this 20 page thing and, you know, it's got ether in it. So you're falling asleep by page two just. Wow, no one wants to do that. With an automated infrastructure, what I love about that story, Ethan, is that you make the point that your automation becomes your documentation as you move forward. You have no choice but to follow it, and it's enforced in the process because it's enshrined in the automation infrastructure. So that is a great point for sure. –

So in that sense, a business person may be listening to this. That's where that preserving institutional knowledge comes in because what would have been back in the day, some post that someone wrote that ended up in a corporate Wiki now has been enshrined in process via an automated workflow. And so your risk losing that human that moved on to those greener pastures is now, in a sense, still existent in the workflow when you've got people that can run that workflow. Now there's still a loss, Tim, in the sense that… Well, if the workflow breaks or the automation needs some updating, you're still going to have somebody with some institutional knowledge that can keep that thing up to date, right?

Yep, you got to hire right. You got to hire a different skill set for this, you know, for network automation, engineering role. And so we're kind of tying our points back together here. It's important for HR to understand you need to hire a different skill set, different skill set with a different pay expectation on top of it. This has to be present or else, you know, you're going to be left with hiring people who are like, What do I do to fix this? I don't know. And then no one knows how to use it. If people don't know how to use the automated infrastructure or maintain it or fix it. It's going to go by the wayside, which is why the culture becomes more important in the long run rather than just having a technology stack to work with for sure.

So, so we're not saying staff retention no longer matters and so on. We still want to keep those people on board if we can. Right.

Absolutely, yeah, you know, the longer you can keep people on and keep them growing and they'll keep your organization growing and staying efficient. That's a huge part of it. Now, when you do have to hire another person though, what's great is when they walk in the door, a lot of the mundane details you might have to worry about in a manual process are abstracted away by the automated infrastructure. So this new person who walks in the door, can get to work right away on high value tasks versus reading procedure docs and writing down manual processes and following them. They can just communicate intent to the infrastructure and go from there. Big difference, big difference in how you interact with your technology.

But again, you know, communicate intent to the infrastructure is a human with a particular set of skills. And then be again, being able to update those workflows as the infrastructure inevitably changes.

Yeah, yeah. You know. That is the network engineering part coming out now, which is why a network automation engineer is so valuable because one, I can help automate workflows. Awesome. But also I can exercise the part of my brain that knows network engineering. So I have the context. you know, in my brain to communicate intent to an automated infrastructure. Again, it comes down to a different skillset than a traditional network engineer. –

I've got this engineer on staff now. I am managing this human and in the olden days, maybe I looked at what they did and measured like the number of change requests that they went through the number of help desk tickets that they service store. some, something like that, Tim does how I measure them and how I interpret via some kind of data. how successful they are, how good they are at their job change if they're working in a culture of automation.

It certainly has to. If you try and stand up a team of network automation engineers to start transforming how your business is doing work, you can't measure them by the old manual ways that you used to do. For instance, how many changes they do, have they parsed this data, whatever. It turns more into things like– We need configuration, we need Jinja templates so we can generate our golden configs. We need to, you know, create Ansible playbooks to run so our orchestration infrastructure can perform these tasks in a certain order. If you measure by– you know, the old ways of doing things, these necessary tasks aren't going to get done. Your staff's going to have a conflicting mandate. Well, I'm being told to do, to automate, but I'm being measured by, you know, how many change windows I do or, you know, how clean my, how good I am at the CLI or something else that's… completely irrelevant to how our network automation engineer goes about their tasks.

You're talking about measuring a very different set of artifacts. So right in the olden days, it would be the things I touch, the things I changed, tickets and this sort of thing that usually resulted in some human logging into a device and typing commands and magic happens. Now we're talking about, you gave some very specific examples, one of which was, oh, you said Ansible Playbooks, you also said Jinja templates that you're generating. While… those are different artifacts that enable the configuration of the network at a wide scale. That is, I can build this template and use that template over and over and over again, or I can have an automated workflow that leverages that template over and over and over again, which is far more valuable to me in a culture of automation than me being the one that goes in and manually types the thing of the templates kind of all in my head and comes out through my fingers when I type the things in the key. So, so again, the artifacts that we're measuring are related to how does this bolster my automation platform within the organization that that's the point you're making, right?

That's correct.

Okay. It's okay. So, so, so let me, let me think out loud about this. Not I'm, am I going to be making new automation templates all the time as a network engineer working in an automated environment? Is that something that comes up that often?

When you're getting it off the ground, you'll be doing a lot of templates most likely. But also, as the network evolves, you might need to tweak some templates. Let's say you have this golden configuration that's worked, that's worked, that's worked. And then all of a sudden, it stops working. Let's say you have an outage, and someone has to come in and make a change directly to the device to resolve the outage. It's going to happen. Typically, it's going to happen. And now you have a non-standard configuration there. that solved your outage, but is now not compliant with your template. So as a human, as a network engineer now, and even a network architect, we need to figure out. Do we need to update our templates? Or do we need to create a whole new template for a new device context that wasn't in the network before? Or do we just need to bring this device back into compliance because it won't go into an outage state if we restore the gold into the ideal config for that device? So that network engineer part of the component of the brain needs to be able to make those decisions, make those distinctions. So and then update the automated infrastructure accordingly. In this case, maybe you need to change a template or create a new template for a new context that's appeared in the network because networks evolve without even us realizing it sometimes that the demands on the network evolve.

Do you have thoughts on how I would measure an engineer's competence with a particular tool? And the root of that question is, Tim, again, in ye olden days, we'd measure with certifications or that was a way to do it. Not a lot of business, not all businesses cared about certs, but you could say if someone was a CCNP on staff, Cisco certified network professional, that that demonstrated some certain level of competence and some orgs, they'd even incentivize a certification by saying, hey, we're gonna give you a raise or a bonus or something if you earn with automation automation tooling. I mean, there's some certs out there like there's some Python certs you can earn. I think Red Hat has a somewhat pricey Ansible cert that you can chase down and so on. Are certs still the way to go there or would you measure some of these skills in a different way, I guess?

you know, as I think about this, I would… I think I'd measure a couple things just off the top of my head here. One, I would measure when you're building the infrastructure, hey, let's get these templates done. Let's get these templates tested. So that's kind of in the startup phase where you're building the infrastructure. That's pretty easily measurable. Do we have the templates? What templates don't we have? Do the templates work? fairly easily measurable. As I think through this, going through this a bit more, I think I would want to measure on the outcomes that are desirable in an automated infrastructure. Meaning, as we've implemented automation, how many outages have we had since we've done that? You know, start to look for, I would start to measure on how well are my devices remaining in compliance.

So you'd need something that goes out on the network and measures, you know, the configured state versus the desired state, the engineered state compares them. And kind of that, that gives you a little bit of a report card, but also, you know, things like outages, they start to matter and they should start going down as your automated infrastructure evolves. And that, that I think is very fair to point out because we know from a variety of surveys that have been published over the years, a very high degree of outages. unexpected result, the network was down. And so that's, I mean, it's a little… It's a little hard to conclusively quantify, but yeah, I mean, I do think that that's fair. If you're running in an automated way where you've defined intent, you've got golden configs and all the more devices that are compliant with that scenario should result in a lower outage count, more minutes of uptime in the course of a year, let's say.

Yeah, you know, and another thing I would measure as I think about this further is, you know, as network engineers, we've all I mean, we've all done dumb stuff that may or may not have caused an outage and you undo it and hope you didn't cause an outage and then kind of go home from work and hope that, you know, you're okay. You know, that ridiculous stuff like, you know, I can tell you how many times when I was in the customer facing knock at one of my prior jobs where I want to make a change to device. Great. I log in, I make the change. Oh, I'm in the wrong window. Oh my gosh. There's, I had five windows open. I typed in the wrong window. Crud. Okay. So now there's a whole thing. Okay. Stop, stop. Can you help me undo this? Okay. Yeah. I'll help you undo this and just kind of sit there and then act as small in your seat as you can until, until you realize that you wait for the phone to ring, wait for someone to go over those. I'm not answering that phone. No way, man. I'm not going to pick that thing up. So, you know, as engineers, we all know what we've done. cause an outage or potentially could have caused an outage. So as a manager, I would say, okay, you know, all right, now we've got an automation team. You know, I want some ideas on what we can build into this automated infrastructure that will prevent us from doing. ridiculous stuff that we've all done in a manual regime. We can build safeguards into our automation. That would be another thing I'd measure is just how many the ideas for that kind of stuff. because that is important as well.

So you're getting at something I like to call cowboy configs, where you've got these oddball things that are out there, these artifacts in the network that are not compliant with business intent, let's say, and with golden configs, because someone went in and made a change. The cowboy went in and just made a change. They went old school. They logged into the device. They made the change. They didn't use– the automated tooling that they should be using, which gets back to our culture questions. So is there another way to evaluate? engineers by saying, Hey, you've been here for 20 years and you know our culture or you know our infrastructure very well. and you need to adapt to the new culture of automation. You don't, they seem resistant to the change. Let's say.

Yeah, certainly. And this goes to the heart of, you know, call it the network engineering culture that has to change. When you tell someone the way you go about your day, the things you're going to do, really the way you live your life for eight hours a day, at least, that's going to change dramatically. That is a cultural change. And, you know, as we see in the world around us, when there's a cultural change happening, oftentimes there's a backlash. And what you just described there, this, you know, I know we're automated, but, you know, I know how to work the CLI, you know. automation's for idiots. I know how to do this manually. That is a backlash. That indicates there's a potential culture problem that needs to be addressed by this, by management and by that person's peers, to be honest. That's not how we're going to move going forward. And educating the people– on this over time is how you help solve that. Because you can walk up to someone and go, you know, we're automated now and oh no, no, that's just for people who don't know what they're doing. You know, I know what I'm doing on the CLI. But that has to change moving forward. And so you have to keep having a conversation with those persons, maybe communicating with them in different ways. This can help you. You know, that cert you just got the other, you know, last week that, you know, CCIE cert or whatever, that did two things for you. One, it gave you high level engineering knowledge. Awesome. Two, it made you great at the CLI. Well, cool, but let's put that CLI part aside. Let's focus on that high value, high level engineering you learned. This lets you do that. instead of focusing on the CLI. Because focusing on the CLI is going forward is there's going to be less room for it. It's, I don't think it's ever going to be obsolete, but I think there's going to be less room for it and you're going to limit yourself.

So to bring some engineers along that are resistant to a automated culture and trying to help an organization move into that world of automation, there's carrot and stick. We've sort of been applying, you know, stick like, come on, come on, do it the new way or you're in trouble. But the carrot would be, hey, as you develop these skills, we're going to compensate you differently. So, and I guess the question is, is that fair to say that a business should be compensating engineers who add automation tooling to their skill set? Should they be compensated them differently? And what does that look like?

Yeah, if they want to keep them, which they should, they're going to have to. The market's going to demand it. If you're trying to hire network automation engineers right now, it's tough. The job market is tough because it's a unique skill combination. So one of the ways to solve that is to grow your own. But you don't want to– and sometimes as management, you can look at something and go, well, I'm not going to train my people because then they'll just leave. Well, why would they leave if you're training them? People want to be invested in, but they also want to be compensated fairly because on LinkedIn or whatever, If you have a good skill set, people are gonna be seeking you out, offering you opportunities. So as an employer, you wanna one, invest in your people, that's gonna build loyalty, but two, you need to keep the people. And that necessarily means you might have to change how you compensate them. On the other hand… If you step back and look at what you're getting for that, maybe additional salary for this group of people, you're getting a group of people that has amplified capabilities that can help automate your workflows, that is contributing more directly to your high level strategic objectives. Management has to come along as well. So the education needs to happen at the at, you know, in the network engineering level. and at the corporate level. or else it's going to fall apart. Your project's going to ultimately fail, and that's sad.

So you've said a couple of things here. One, okay, you confirmed. Yeah. If they're getting automation skills, you will need to compensate them more highly. So you need to value that as a business manager and as an HR person. You know, we need to know what the salary range is going to be. So you're, one of the ways we value that is just like, okay, they have more skills. And so there's more inherent value there that they're bringing to the organization. You just described that. But then also there is a risk that is being mitigated by compensating them more highly in that. you're going to lose them to Someone and the markets global Tim with remote work I mean, where they can go just went from everybody in town to everybody across the country and maybe even around the world.

It's shocking. I love that point because that's a whole other variable in this equation is that we're in a global. labor marketplace now. You know, with a certain skillset, you can work for any, you know, for any business in any country, really anywhere. and be just fine. So it is the business is going to have to understand that and hopefully they will with the right. with the right education, speaking in the right language to the business people. Hopefully that can take care of that. At the same time, the network engineers need to be brought along as well. And another way we haven't talked about yet is educating the network engineers. It's intimidating to walk in to work and just be told, okay, We're gonna ease into it, but your days going forward are gonna be different. Here's how. I would have a massive freak out just with no skills. I'd be freaked out and I'd be probably pretty upset and very resistant. But the business is going to say, hey, let's educate you. Let's get you versed in Python. Let's get you versed in Ansible. That will get you going and at least understanding what you're supposed to be building and start contributing to it. –

Okay, so compensation is a piece. Training is also a piece is the big thing you just said that, Tim, I have, I want to say almost never worked for a company where training was part of the budget. It was always, figure it out on your own and often on your own time. And so you're making an important call out to the business managers here and to stakeholders saying they must facilitate this learning of network automation, network automation tooling by saying, we're going to skill you up on whatever the list of skills are.

Yeah, it's part of just kind of growing your own, you know, network automation engineers. Education has to be a part of that. You can't just show them how to use Ansible and then, you know, for an hour or two, then, you know. put your hands together, we're good to go here. It's so much more than that. The engineer has to feel comfortable in the new environment. If they don't, it's bad for everyone. One, the company is going to lose an employee. And two, that person going forward might think that they never want to deal with automation again and severely limit their career going forward, which is which is a tragedy

So the education component is so, so important. And it's a business facilitator. This is not an expense to be managed and controlled. This is an investment in the business when you train your IT folks to have this skill set. You are enabling them to deliver network infrastructure in an automated way that has specific business advantages. If you do not invest in your people and give them these skillsets, then you are reducing your own business's ability to compete in the marketplace. And so there's a mindset change here, I think that again, a lot of businesses, they get this. They understand this from a technology perspective already, but so many just don't seem to.

Yeah, and there's some tough lessons. You know, sometimes it's a tough lesson to learn what you need to. I know I've had my share of tough lessons in a lot of ways. So, you know, sometimes you learn it the tough way, but eventually in order to compete. You're gonna have to come around. to you know, the way… You can have to leverage all the capabilities you can to deliver the most value to your customers. Network automation is one of those advantages that you can leverage to do better for your customers. And also, as we've described, do better for your people. This can be win-win, but it doesn't happen without the appropriate culture. And this is why we're here today talking about this, because it's not apparent. If you just look at network automation on a Google search or whatever kind of search, you won't see, I don't think a word of culture, at least not like, I think I looked for five or six pages last night and there was nothing there.

So maybe a way to tie this conversation together, Tim. How? with the business stakeholders or maybe who starts the conversation with IT. an IT sort of a change that IT would need to go to the business and say, hey, this is what we want to do and why and bring them aboard as opposed to business initiating the conversation because they don't know what they don't know, right?

Yeah, I think it would depend, but you know, a lot of times. What it will depend on is someone, you know, someone somewhere being able to communicate what you want to do in terms the business can understand. And we'll link back to those high level strategic objectives that automation supports. That is a good place to start the conversation. Also, you know, within a given specific company, you know, if I wanted to start the conversation there, I would look at my corporate high level strategic objectives. and then figure out how automation folds into those. Because we've all seen how it works in corporate America where the business has its objectives and then every layer down makes their objectives based on the higher level objectives. And by the time it gets to the individual contributor, it's so abstracted and obscure. You're like, I'm just trying to do my job. I don't even know what they're talking about anymore. But if you can speak to the business in the terms of their– specific direct high level corporate objectives like the ones that come from the C level. you'll have a better chance of one, making your point and two, getting funding. So that messaging, understanding the business aspects of it and your specific firms. high-level objectives. That is probably the best way to start the conversation. Otherwise, you're probably going to be back to, oh, more toys for the engineers. They don't need that. I don't care if they can provision of VLAN 10 seconds quicker. It's not about provision of VLAN 10 seconds quicker. It's about using that step in a workflow that delivers value. And now when you should talk in value and cashflow and intellectual property and all these other things we talked about. This is where you can start to get the business's attention, if you can get it at all.

Well, if you're out there listening to this podcast, maybe this is a podcast you forward to your manager to some key business stakeholders that you work with. Cause this conversation, it had its nerdy comments and specific jargon that we talked about, but the intent was for them, the business stakeholders to kind of think about this cultural shift that can be brought about by network automation. And maybe this puts it in the language that can be used to start the conversation within your organization. Tim, this has been a fantastic discussion. I've enjoyed it immensely and read that blog post of yours that facilitated this conversation and was immediately excited that we were talking to the business. Now you've written a lot, you've got a lot of publications and things out there. If people want to follow you on the internet, how can they do that?

Sure. I am on LinkedIn. I'm just Timothy Fiola. I also have a personal webpage for it's kind of like a clearinghouse for my technical and personal blogs. It's a lock. lock s foils.com. It's lock dash s dash foils.com. You know, I have links there to all a bunch of tech blogs that have written that are native to the site and also have links to, you know, blogs I've written for APNIC and packet pushers as well, you know, including, you know, how to negotiate a good salary. how automation conquers the fast, cheap, reliable paradox, all that stuff. But on lock as well as .com, there's also a personal blog section where I cover stuff like why tequila is awesome and, you know, a tortilla chip cover up that's just huge in my opinion that I'm really disappointed about. You know, what I think about people posting pictures of their food on Facebook. I don't care. That's a spoiler alert. But if you're kind of in a cheeky mood, take a look at the worldly observation section of that web page. Hopefully for a laugh or just it made me laugh. I can also be reached in NTC Network to Code's public Slack channel. If you go to slack.networktocode.com, you can join the Network to Code community. the public community and also I'm reachable there as well. And then again, you know, in the show notes, maybe we can add links to my, I wrote a couple of books for Juniper Networks that are available with, if for free in PDF form. –

Oh yeah, part of the Day One series. Then you've got it this week to playing MPLS and so on. Yeah, Juniper has been great about making a lot of information like that available from a lot of different authors. And Tim, I think the last time you were on the show, we were talking about your pyNTM project. Is that still something you're working with?

It's still something I'm doing. Yeah, so the short story is if you have a WAN, if you're trying to plan a WAN, a wide area network, a backbone network, it can become really complex to understand if a failure happens, where does my traffic go? Should I add a link? Where's the best place to add a link? What links are at risk? What failure should I care about? A simulation program can answer those questions for you. And pyNTM is an open source wide area network simulation engine where you can define scenarios such as if my traffic increases by 10%, can my network handle it? If my traffic increases by 10% and something fails, can my network handle it? It can let you game out these wide area network planning. tasks that are not that are not really doable manually. So yeah, go ahead and take a look at that. It's on GitHub.

So clearly, Tim, you have figured out how to figure how to put more than 24 hours into a day. You are quite prolific in a lot of ways. And, and again, Tim, Tim's blog on Network to Code networktocode.com/blog. We're going to link to that in the show notes. Tim's also appeared on the Zigbits podcast as have I over at zigbits.tech. where you had a conversation with Zig about how to differentiate yourself as a network engineer. Tim, you're out there, my friend. You're everywhere. You're out there, you're sharing information and we appreciate that. –

Yeah, I– It's been a pleasure being here and I really appreciate you having me on. And I hope this was helpful to the community 'cause it's important. –

Well, it really should be. I see this as an episode that again, if you're out there listening forward this one on to managers and business stakeholders to get a conversation going about network automation and the business value that it creates within your org and get support, get them on your side. And maybe that culture changes in the way that it needs to change.