Welcome to Total Network Operations, the podcast dedicated to hardworking NetOps teams like you who deliver and orchestrate all the packets and all the workflows. I'm your friendly neighborhood pod host, Scott Rolbon. On today's episode, we have the distinct pleasure today of having two friends with us. Ethan Banks, my friend and oft collaborator, writing along with pithy commentary and questions for our esteemed guest. Ethan, are you ready? I'm ready. I'm ready, Scott, and flattered that it's a distinct pleasure that I can be good with you. Is and that warm chuckle that you hear is a new friend, Jesse Ford. He's a longtime networker and an automation architect at iTension. I first came across Jesse a few months ago around his interest in getting people together around automation collaboration in his local area. So I knew pretty quickly that he's the kind of person who wants to get folks together to share technology and ideas, like warms my heart. So we're gonna get him to do a lot of that right now regarding automation in the real world. So let's dive into the conversation. Jesse, welcome. Thanks for coming on the show today. Hey. Thanks for having me, guys. Appreciate it. No. It's it's awesome. Tell us a little bit about yourself. How did you you know, little brief version of your networking history. I think you've got some military experience. I'd love to hear how that informs who you are and what you do and what you're doing at iTential. Sure. About twenty five, close to thirty years in the industry, various types of experience, a decade in the Marine Corps doing IT communications, moved into the service provider world at Verizon Wireless, then hopped over into the enterprise world for another decade or so. And about seven seven ish years ago, I started playing with Python. I started the automation journey. And over time, here I am now as an automation architect with iTentil. I I think we might have a little throwdown on who we feel are in, like, the most beautiful parts of the United States here. I think Ethan and I will just hang back, but, like, tell us a little bit about you've got some other stuff going on around you that, you know, I think is not tech. Tell us about where you're coming from. Sure. I live in Tennessee now, about thirty miles north of Nashville with my wife and my six children. We live on a farm with I don't know how many chickens we have now. Horses, dogs, cats. My kids run around, you know, barefoot, blue jeans, playing in the mud. You know, just good old country living. Nice and relaxed. Well, you and Ethan, I think, do some of you know, a lot of that playing in the mud. So good for you guys. Right? Definitely playing in the mud, although although my kids are long since out of the house, Jesse, so you're you're behind me. But you don't need those kids anymore to play in the mud from from stuff I read, but all good. No. No. No. No. I do run-in the mud run around in the mountains where there's lots and lots of mud. Hey, Jesse. Just a quick quick question about your intro. You mentioned Python is how you got started. You jumped into the deep end using Python for as your automation tool? Yeah. I mean, when I was in the Marine Corps, we dabbled a little bit with Bash to automate some alarm response and things like that. We actually, way back in the day, used a little bit of bash and GPIO boards to put a speaker. So when certain alarms fired, we'd fire an audible funny sound so we know whether this alarm was worth getting up from the movie we were watching to go deal with or, hey. You know, we can ignore that and go back to what we're doing. And from you know, just like I said, seven or eight years ago, there was an issue at work needed a quick remedy. And I said, hey. I'll take a whack at it. Let try Python, and was able to get a script together to take at that time, it would have taken two to three weeks to update a few thousand devices to a few days, and it kinda just set that hook on, this is cool. I'm gonna keep going. I was gonna ask you about, like, operational discipline from being a networker in the Marine Corps. You were doing networking stuff when you were a Marine? Were you a Marine? Yeah. And and, you know, until you said, you know, bunny sounds and other fun stuff, it's like that didn't quite fit the the Marine Corps view for me, but everybody's got a sense of humor. Right? Oh, so, yeah. I mean, you know, the job that we had, we were we were one of one most often. So anything we could do to make to improve our quality of life, we were gonna do it. You know, we were the architects on steroids when it come to the Marine Corps communication systems. So if I didn't have to get up out of my chair more more than I had to, there'd be times where we'd be staying away three, four, five days straight. So anything I could do to improve the quality of life, we were gonna do it. Yeah. That's that's a motivator for sure. So let's let's pull on the right tool for the right job theme and that journey from Bash scripts to Python. How did you get down the Python route as you've evolved? Sure. You know, at that instance, we had the issue. I'd been kind of shadowing a guy that I another former marine that I worked with who had built some stuff. And he was very high code, you know, c plus plus dot net core. I was like, that's that's too much too too much too hard. You know, I'm a marine. I want it simple. And I kinda latched on to Python because in relative terms to other, you know, compiled coding languages, it made sense. It was more human readable, easy to learn. So, you know, that's that kinda what drew me to that tool. You know, allowed me to develop skills fast, solve use cases fast. So it kind of, you know, was almost foreign gaslighting on the fire of learning more or less versus trying to learn a compiled language where I had to think about low level system memory and CPU. So it just made sense to me. Yeah. Plus the ecosystem around Python is huge. All the different libraries that are out there, all the different tooling that other people have built to make it. It's like a cheat code. You can do Yes. So much work done in, two lines of Python. It's incredible. Yeah. Lots of Legos. There are lots of Legos in that box now. But but when did you start this? Like, was that was that true when you got started with Python, Jesse? Or have you seen all the tooling come along over time? I had dabbled with it a little bit before that incident happened, kind of learning from Nathan at the time and figuring out my own path. And like I said, when that incident happened, it's like, sure. Why not? I'll take a whack at it. And, you know, convince my bosses at the time to to give it a go on the production network. You know? That was quite a a story in itself to get back to them, but, hey. I'm not gonna crash the company by doing this. You know? And it really made me have to think about, do I really understand what I'm doing? Because I had to explain it to them. We're training force for learning. You know? It's not just going today, to an AI and just busting out a piece of code. I had to do the research, handwrite it. So I really had to know and explain to them how I was mitigating potential problems, how I was gonna prevent it from taking the company offline. And that kinda reinforced back to my Marine Corps days in the way we were we were taught to do communications. You know, at that time, you know, we're supporting combat operations. Comms can't go down. So it should that mentality is just carried forward with everything that I've done. Yeah. Yeah. That's that's an environment that most of us haven't operated in. Right? When there's there's there is we use the term mission critical very loosely. You know, most of us, especially us civilians, I think you have a very literal understanding of mission critical comms. Yes. Very cool. What else, Dee, comes to mind when you think about, you know, right tool for the right job from a networking toolkit perspective? You know, there's there's kinda, you know, not just one way to automate things. Right? What what other stuff have you have you seen that you've dived further into or you've decided to stay away from for one reason or another? Sure. Yeah. You know, when I worked at Verizon Wireless, y'all was part of a team that was using Ansible to set up a private cloud with OpenStack. You know? And, you know, started playing with that a little bit. It worked for that because it was, you know, standing up servers, imaging servers, real simple stuff. And then at that point, I was executing what an architect had given to me. You know, I was in the just baby learning stage. And then when I moved into the next role at Asurion, where I had that initial Python script, I was like, you know, that took me a long time to write. Sure. Then I I was like, well, let me introduce Ansible into network automation. And I learned quickly that there were gaps. This Cisco with this OS, the command wasn't present at the back end. So I had to delve into the back end of Answers, learned how it worked, and that's where I began to start thinking about maybe Answers is the right tool for this because it's gapped in this scenario. So I started to develop a methodology of looking at the tools, the Terraforms. Where are they strong at? Where are they capped at? And start putting the Lego blocks together to find the right combination of tools. I'm kinda fond of saying the right tool for the right job. There's no no one tool's better across the board than any other tool. So it's, you know, just figuring out what works. I'm gonna guess, you know, like, okay. If you've you've been doing telco cloud stuff with OpenStack, so you've already proven yourself in many ways there. That's not simple for anybody who's ever touched it. Did you make any any bad tool choices there? Things that other things you found that, like, I'm just gonna avoid this going forward. I I'm not trying to make you talk bad about anyone or anything. We've all had to retract certain tool choices. Like, any good examples there? Sure. Yeah. Not too long after we started our our initial automation journey, I was still a baby, relatively speaking, in doing this. And I started researching. I found NSO, Cisco NSO. Great product. A lot of good capabilities. But where I was in my journey at that time, it was not the right tool for me. It was moving the the Cadillac when I was just got my driver's license. You know, dad's not gonna give me the Cadillac. I didn't know what I did know and what what the right questions were to ask at the time. So, fortunately, with the the mentorship of my boss at the time, we came to a decision that the Cadillac wasn't good for us. Sure. You know, we were we were going to get way out of our depth and our capabilities, and we weren't ready for it. And that was a a great lesson to learn, you know, because I learned, you know, through him a little bit more about and the business, you know, thinking about how the business works big picture, not just how you know, thinking about networking. And the and the considerations beyond just is the router up, is the switch up. And that laid the foundation for some of what has come to become by foundation for presenting automation tools and the ROI on a tool and things of that nature. I started developing that kind of big picture awareness. So let's pull on that thread a little bit. You talked about high level business objectives or mission objectives a few minutes ago. I'm not gonna take the network down. I'm not gonna break this. Right? But it's more than that. Right? You're actually caring about ROI and building a business case. We've had some interesting prep conversations around that front. So as you landed at Asurion, which is headquartered right there in Nashville, is that right? It is. Yeah. It is. What what process did you go through to, like, build a more detailed business justification for what you were trying to do? Sure. My second round at Atasurion, know, everybody could see my LinkedIn profile. I came back to a full automation role. And from there, I picked up what we affectionately called our NetOp tools. It was in the house built product where we front ended a lot of Python scripts, a lot of custom built homegrown high code solutions. And we continue to add tools to that that benefited the business. Had an extreme amounts of ROI. Sometimes it was high between two hundred and fifty to three hundred times, four hundred times faster execution on manual tasks. So the business loved it. And what we ran into a problem is scaling this out. What I was a three man team and myself, and I had two other automation engineers, and we just could not keep up with the high code development and the amount of benefit we're bringing to the business with all these tools. So we was there a mix at that point? We had one tool that was simple data gathering. So when we think about in the in the network or in the enterprise, somebody calls you for a problem. Hey. Here's my IP. I'm having this issue. Or, you know, what is this IP? Well, you're gonna go log in to this platform. You're gonna go log in to this platform. You're gonna log in to all these u disparate UIs, and you're gonna swivel chair the data from each one to get a picture of what this is. So we went and built the a alter automation that would touch all the APIs of these in one spot. So now instead of a fifteen to twenty minute time logging in to these different platforms, you know, your ServiceNow, your info boxes, Now you just drop your IP in. In about three to five seconds, you've got a full report on every one of those technology repos on the identity of that IP. So Yeah. So with that tool as an example, was the scaling problem you were having as a team just keeping up with the development of the tools? Oh, well, it was when we had that tool, we had probably eight or nine more. And, you know, we started to go beyond the just data gathering tools, and we wanted to start doing making real changes on the network. Because initially, we were another one was, you know, load balancer technology. Hey. What is the status of this? And if something just makes it faster for the business to sell service, what's going on with their equipment or with their environment? And once we got more mature in our team and we felt more confident, hey. We could start executing changes on the environment and at scale. And then we then we start talking orchestrating a firewall to a router to a DNS system. You could do it with high code and Python, but that's getting to be really, really complex. And the time of development relative to the value to market was really the scale wasn't there. It was tipped in the negative side, I would say. So we had to start thinking about what do we do next? How do we reduce the complexity that goes into developing high foot solutions to start orchestrating multiple systems together and move beyond these targeted single automation tasks. Go gather this data, bring it back. That gather this, bring it back. And so we started talking to some of our partners, some of our connections in the industry. You know, a lot of folks come back to, well, you could get AAP or Tower at the time, and you could stitch together playbooks. And Tower is what you're talking about. That's correct. And it was like, yes. I could build workflows of multiple playbooks, but I still go back to my previous statement about, you know, I'm in the network scenario. There might be a gap in command with this OS or that OS. So it really did not scale well for us. And then we looked at a few other solutions in the market that requires still a lot of high code to build the integration. And then through one of our partners, we were introduced to iTential as an option. And, yeah, I did a lot of research into iTential, watched a lot of their videos and a lot of their products, and was able to determine that this was the way we wanted to go. It was the only to allow my team of three to effectively have a force multiplier and double or triple our capacity because now I can make API calls. I can work with data much, much easier, and I can much more safely take my Python script and serve it as a service to a much larger scale audience much easier. And so, you know, we started our journey with iTential, bringing that into the organization. So so that was a a question I had. Did iTential replace the tools that you have, or did you integrate your tool set into iTentional? Because there's bunch of different ways you can use that platform. But it it sounds like you did some tool integration, and iTentional became the the layer on top that you interacted with to use those tools. That is correct. The businesses already have a comfort with the UI we built, with the tool we built, and how it worked, we just simply reworked the back end and used iTentional as that back end framework, and it made it much easier for us to scale out. We were able to take some of the the activities we might've had in the high code Python script, move it to iTentulous Canvas, and then make the API calls and data parsing there so I'm not having to do all that high code execution. Okay. So define scale out. It sounds like you're talking about humans scaling out. That is you don't have to sit there. You keep saying high code, as in writing Python code, writing you're configuring actual the scripting language itself. You don't have to do that so much because you've handed some of that functionality off to iTential and the Canvas and so on. And so when you say scale out, you're talking about you and whoever else is on your team is able to get more automation going more quickly because you're not sitting there hacking on Python. Right? That is correct. And then I also lowered the bar to entry for someone to build automation because now someone who is not a Python developer but can think about the process can much more easily go into the canvas, and they can lay out their vision. You know? Hey. I want this to do these processes so they could go in and lay out a sixty percent solution framework that now myself or one of my other automation engineers could come in, fill in the other forty percent, and we can move faster with their ideas to market. So they're not waiting on us to go through a full development cycle, write the code, test it. So it made us be able to get their ideas to market a whole lot faster, which made them happier. So a comment and a question just to, like, make sure I play that back to you. Like, you're talking about taking idea. You say process. I say workflow. So you're defining a workflow within the tool. You're not requiring people to use Python to spell that out. So I'm understanding that correctly. Correct? That is correct. And now you've got this impact where you and your team, it sounds like you had a high level of proficiency in writing Python, but this changed what you needed for additional people coming into the team. Like, you see this have a real impact with now, like, writing Python is no longer a job requirement for for newer team members or lower proficiency? Was that a particular impact? That is correct. Yes. I could take a great example is another gentleman that I worked with in the Marine Corps, we've been together following each other in our career for the past twenty plus years. Very intelligent engineer, architect, and he could go in and describe his process. Hey. I want you to go from this product, and you need to pull this from here, go here, do this from here. And he could framework the whole end to end workflow within the Canvas and give me that seventy five, eighty percent solution, and I've just gotta go do the little tweaks to make it work. So now we've we've effectively democratized the architecture and the solution of an automation. Yep. Because these guys always had a backlog from the the ops team or my network architecture team of, hey. I want you to do this and do that, but they lacked the, what, the the ability to write the code to give me the framework. Now by employing IT, so they could give me the framework and a backlog that now my team doesn't have to start from scratch. We're starting from seventy, eighty percent sometimes. Off the top of your head, can you, like, quantify that backlog reduction? Because I know that was a big deal as we talked about, you know, getting ready for the show. Like, how how quickly were you able to drain that swamp? A lot of times, I mean, we would have dozens and dozens of, hey. This is a good idea. That's a good idea. Sitting in an email somewhere or sitting in a Jira task or something. And now those dozens of backlog requests were still there. But instead of going having to go through the whole development cycle from solutioning to architecture development testing, I just had to do fill in the variables and get it out the door. So we probably cut down deployment time forty, fifty, sixty percent sometimes or more. Yeah. That's awesome. Who doesn't want that kind of help? No. I would like to spend more time on every task that I need to do. I would like these podcasts to take longer. I really feel it, Ethan. So alright. So now I wanna set a couple phrases that will strike fear into the hearts of any enterprise IT organization. PCI compliance, you know, no that doesn't usually attract lots of, yeah. No. I wanna work on that project. And and in context, you introduced me to a new phrase, time vampire. So I want you to weave your story together on this PCI compliance project that you've talked about. And what is it? What does it mean to be a time vampire, Jesse? Sure. Yeah. We've all been junior engineers in some company somewhere, and the junior engineers wanna get stuck with the drudge work, the not fun work. And that really has an impact on the brow of that junior engineer and potentially impact their longevity in the organization, which ends up with churn, which, of course, has an impact across the organization for effectiveness of the IT department. And, you know, with PCI audits, that's hours and hours and hours of artifact gathering, data validation, and the the senior architect isn't gonna spend that time. So now your junior guy is stuck for weeks and weeks or months staring at spreadsheets and rolling logs and correlating data. And that's not what they got into IT to do, but it's what they're doing. And it you know, one of the things that I get often asked is how do you decide what automation to build? But it's you can go, like, well, what is our top ServiceNow ticket? What is our top whatever? But sometimes when you look for these opportunities to help out the team in a in a way that is not always apparent at first, such as PCI audit. You know, you approve the morale overall, not just in one team, but in multiple teams in the organization. So I I recognize this, you know, from having done it myself and looking at some of my counterparts on the network operations team. And I thought, man, I could help with this. I had become pretty proficient with Splunk searching, helping in lots of things. So I started taking a look at how can I automate that audit process? And I developed a process, basically a Python that went to pull multiple haul datasets, pull datasets from ServiceNow and other other resources that would take that, What would take a human, we estimated, a few hundred hours to go through at any given cycle down to minutes to compile the artifacts, do the initial analysis, look at you know, for instance, I see the this rule passing this traffic. This is active directory. So automatically, we're gonna check the box that that's allowed because it's a business service. And Yeah. On your on your time metric there, I just wanna point out, like, this is not network change. This is read only gathering data. That is correct. And and you're you're yeah. An a nondisruptive, fairly safe operation going from hundreds of hours to minutes. That's impressive and notable. Yep. And that is correct. And, you know, as I that was the version one, and I've evolved by the time that I departed that organization, I evolved this multiple versions. And the final version could process a single IP through firewall, DNS, authentication, user identity, metadata gathering, and construct the model in about six seconds per IP. And, you know, this model this automation is not just was used not just for these audit purposes, but now it becomes a security tool. Right. So so now security has an event. They can drop the IP in there, look at what it's been talking to, identify what it is, what the resources has been using, and really helps them with a threat evaluation. You know, they're troubleshooting an incident. Now the firewall traffic isn't just source IP to destination IP. It's Scott's machine to Ethan's machine that's talking and it's doing this thing. So now you get a much more human picture when you're troubleshooting, which is going to enable that read time to resolution to go faster. Yeah. Scott, what are you doing to my machine? That's what I wanna know. We get into my machine. We don't talk, Jesse. We our our machines don't talk to each other. So I under trying to make it real here. We really appreciate that. Yeah. So now you were able to even get to more performance improvement. Right? Yes. You you were able to tell tell us more how how you scaled that up, and you there's this two thousand x number that you need to talk about. Correct. And that's that is at, you know, six second per per IP. So by the time we got to the the most recent version, the calculation was it was an average of forty five minutes for somebody who was trained on the process to manually go through and execute each step of that, correlate the data, and put it into a spreadsheet. See how that Spreadsheets still matter. Spreadsheets still matter. So that was our baseline of an estimated forty five minutes to an hour, and we all had to recognize there's IMs. There's walk ups. There's bathroom bracelet. Time's going to scale out, but we're gonna use a baseline of forty five minutes here for the exercise. So we take that forty five minutes for manual versus six seconds for the automation. So that's where that multiple thousand time efficiency increase comes from. Yep. And now you bought that in that process into iTential to where that's now a service offering. Now that could be used by anybody that's approved to access in the company. So your security teams, your NOC, your data governance team. Anybody that is given the RBAC access can now do that analysis. So they don't have to put a ticket in or call that network team to a bridge. They can self-service. So now we start looking at the expansion of the impact of that across business is exponential. Right. And going back to your junior engineer struggling with this with with scut work comment that you made earlier, you made a lot of that go away, which in in theory, everyone's a little bit happier working on the team. That is correct. And that was that's that you know, every time we talk about ROI, everybody's looking at how much money did I save? What is my time for this manual task to automated task to put a change in the environment? What we don't often think about is the human element. You know, how do how do we figure out how to quantify the positive impact to the human element of these teams? Because now that junior engineer can learn the next skills, and he can feel like, hey. I'm moving up. I've got a path forward. I'm not just stuck in the drudge work. Now they're less likely to leave the team. So now your manager isn't worried about churn. He could focus on the task of the business. And from there, again, it just trickles across the organization. You didn't have people running away with their hair on fire worried about this two thousand x improvement is gonna eliminate my job. Doesn't sound like that has come up in the conversation. Those conversations always come up. And the way I like to frame those is every business has a backlog of work that has to get done. Yeah. Now I've freed up these engineers to learn the skills to go handle those tasks that are in the backlog. So now the app team who's been waiting on this improvement at the environment that was backlog because the audit was higher priority, they could go work on the test. Now the app team, who's the moneymaker for the organization, is happier. But you said there, every business has a backlog of work that needs to get done. Yeah. I don't know why I've never heard it put that way before because everybody talks about automation. It's like, oh, it's not that your job's going away. It's just gonna free you up to do better, higher quality stuff. Well, one of those higher quality things is exactly what you just said, that backlog of work, reflecting across my network engineering tasks. I had a whiteboard that was full, full of all these things I wanted to get to, this endless backlog of tasks that were always preempted, or I just didn't have time, or whatever it was, that could I have gotten them done, were definite value enhancers for the network that would have been better for the business. It would have just been made for a better, more robust network. Never got to them. Never got to them. Never got to them. Sorry. I just that really hit me as a big deal, Jesse, that you said that is. We've struck a nerve, Jesse. We've clearly struck a nerve. That is. I would layer onto that as I've been now doing my own consulting work for about three years now, and I hear this increasingly common comment that we can't find people with network engineering skills to keep up with Ethan's backlog on his whiteboard. So this is becoming a more and more common issue, especially as people choose to do other things. Right? You know, not just new in career, but they move out of the networking space and go and do other stuff. So I think these kind of performance improvements are really solving problems. I don't think they're causing problems. And the the folks that are nervous about it, we got I understand in theory why they might get nervous about it, but when you look underneath the hood, it's really a huge net benefit. Can't can't ignore the two thousand x by any stretch. No. And you can you can really scale that out, you know, to go to, you know, kind of Ethan's comments there. And when you think about, you know, the senior engineer again, and your times being called to this bridge that your your tier one guy just doesn't know the right commands, doesn't know where to look. So now I could take Ethan's playbook for, hey. Incident one, two, three. Here's your knowledge document for all this. I take that, turn it into a automated workflow within iTenture or within Python or any other platform. Now my level one can go run Ethan's automated playbook, and you can build in as much intelligence in there as you want to to analyze the outputs to make a decision and potentially give the level one the answer before they even have to worry about calling Ethan to the call. So now he can go to his whiteboard and start taking things off the board. You know? So that's the power of of automation, and platforms like iChitra really do make it much, much easier to do that because there's the barrier to entry is much, much slower than writing a high code solution or having to learn YAML for Ansible, and then you have to deal with the limitations of Ansible. So there's there's lots of positives to this, the way the industry is going here. And I I personally love editing YAML files, so I don't know what you're talking about, Jess. So you've you've jumped jumped the river. You've made this move from being an end user space to vendor space. Tell us a little bit what were your motivations. You you can leave the paycheck discussion out of this unless unless that's central. And how's what's the transition been like for you? How does your having been an end user and implementer for so long inform how you deal with your customers, how you communicate with your new colleagues. Talk a little bit about that. Sure. You know, iTentro had such a positive impact on the my vision of work and my previous role and was allowing me to be much so much more effective. When the time came for the next transition in my career, I looked at a lot of opportunities and not just iCentral. However, the opportunity presented itself to come here and work with the team and having such a positive experience and with the product and with the organization. I made the move to come here because I felt like my experience as a network engineer all the way up to architect and everything I've done and then my transition into automation could really benefit other client, other potential companies and organizations or people looking you know, network engineers looking to make the transition to have something to look at. You know, when you go into an organization and we speak the same language, you're gonna be much more comfortable talking with somebody who's been in the the trenches. Yeah. You know, who's done the network engineering stuff, who understands what it takes to do a Nexus debt upgrade in the data center and to start talking about, okay. How do we how do we truly automate this? Because I speak the language. I've been there. So I think there's a lot of benefit in the role that I'm in now to combine in my my experience of both worlds to have a much broader impact in the automation world. It's slowly growing. It's slowly catching on. Every company is is always coming down from leadership, automate. And then the network engineers kinda look at automate with the big question more like, what does this mean? What do what do you mean automate? What do I do? And I I've been able to successfully do it. So now I can answer that question at a much broader scope with a great product at my back and a great team at with my alongside to help these companies or to help engineers who are wanting to make this transition. Sure. What what advice would you give to people that are still in the operator chair swiveling between consoles and communicating with their vendor partners? Like, are there any like, I I made that transition, and I know how I would answer that question. I made that transition a lot longer ago, I think, than you have, though. Do you do you coach friends that are still on the outside? Hey. You should ask the question this way, or this will be much more meaningful way to get your get your enhancement request bumped up above the priority line. Yeah. I mean, I've both the people that I have personal relationships with and even to people that I have met virtually through mediums like Slack channels or through LinkedIn and other ways. You know, I've had people reach out, hey. I'm doing this. What do you think? A great example, there was someone I interacted with on LinkedIn, never met the gentleman, but I'd asked the question kind of a office hours. You're stuck on a problem. You need help. Throw it out there. We'll let the community help. And they they threw it out there, you know, and I quickly banged out some suggestions for him, passed it back to this person. He took it back to his organization, knocked it out of the park. And it was just about providing them a little bit of breadcrumbs, a little bit of appetizers, and push in the right direction of how to frame it, how to think about the problem they were solve were trying to solve for. And this gentleman had the moment. And from there, I continued to contact with him, and he's just continued to grow and grow and grow just just from that one little seed that was planted. And those are the kind of things that I enjoy. Because I wanna see other people be as successful as I've become to be able to pursue their their goals or to see that idea come to fruition. Yeah. I I think that's an important lesson learned, and you made a you made an adjacent comment to that earlier. You talked about this other individual where you've followed each other around in your career for twenty years. Sorry if I got the number wrong. You know, I was a person who twenty years ago, I thought chasing the tech was cool. Being an MPLS expert is what mattered. You know, fill in the blank. And I realized slowly over time, because I'm not that easily taught, that your connections to people who, you know, are good, reliable people are more important than the particular technology area you're working around. So your Yeah. Your comments definitely resonate with me there. So Yeah. Jesse, how do you handle the the the issue a lot of network engineers face with automation, where you would talk about the big question mark. Leadership says automate. What does that even mean? Do and a lot of engineers look at their network and go, automate all this? It's super complex. I can't get my head around it. I don't know what to do. Mean, the common advice I've heard is, you know, start with one thing that you can automate and get a quick win. But then the issues people seem to run into is they actually need to build a platform. They need to build system that they can use to automate their network with, and building one little thing at a time doesn't get them there. Do you have wisdom for them there? Sure. I mean, if you if you're that engineer that your boss said, hey. We've gotta automate. Figure it out. But a lot of times folks and I I going back to my NSO example, do you wanna go for that home run? Because you don't know what you don't know. So what I what I always tell people today is start small. Don't try to go make a change on the network. Go do data gathering. Think about something as simple as what what is my common incident call that I get? And then, okay. How can I go write a script for me that's going to make that go faster? Start building your skills there. Build that confidence in your ability to execute instead of trying to go do firewall rule automation or VIT creation right out of the gate. Do the little things. And as you start developing those skills and that confidence in what you've been able to do, then you could really start to assess what can I what can I truly do next? You know, if you try to go swing for the fences, you're gonna jump off the deep end beyond your skill set. But if I was just hey. Go find an IP on the network with a quick script. Start there and just build and build and build, and you will get to a point like we did where you have to start thinking about a platform. And then you just it grows and grows and grows. Is there a way when I'm beginning to build those initial tools that I could be thinking about, I might use this in the context of a platform in the future? Are there any advice there about how to think about that kind of stuff, so I don't end up with a bunch of stuff that's hard to snap together? I think there there's a balance. I think there's a point where you start with the baby scripts, where you're just learning learning Python structure, learning Go structure, your language of choice, getting comfortable in the language and grammar before you need to start thinking about frameworks and platforms. Even for us, we ran a lot of ad hoc Python scripts from local machines for a long time before we got to a point where other folks were asking to run what we run. And, you know, that Ethan had Ethan had his scripts, and they work fine on his machine. Yep. Like, Jesse had your scripts. That's right. Correct. Because, you know, depending on the organization, if you're starting this grassroots as yourself, if you go to your boss and you say, hey. I'm doing this. I wanna build a Jane Go front end about all this stuff, but you've not shown any real value for your idea with the small breadcrumbs, baby steps, your boss is like, no. Go back to your tickets. So it's getting those little wins, building building your confidence in your abilities, and then building your your peers and your your leadership's confidence in your abilities. And then at at some point, you'll get you'll you'll get to a point where your all your buddies are asking, hey. Can I run this? Run that. Run this. And now you've gotten your development skills to a point where you can really start doing that. But it's really hard at day one when you're just barely past hello world to have a concept of a construct of a framework and a platform. Right. You know, it's it's you know, I'll go from building my son building a Lego car. Now, my eight year old son, I want you to go out and take the the engine apart of my Camaro and put it back together for me. He's not quite there yet. Do we do that Star Destroyer first or or even the Death Star one before we before we before we give him the keys to the network or the car, depending on your your analogy here. So Yeah. So, I mean, I hope that makes sense in that analogy, but that's the best ex best advice I can give is you gotta cut your teeth a little bit before you you you try to do the the big stuff. That's completely fair. I do wanna look a little facing forward, and here's how I'm gonna make this transition. We've made it this far without using those two little letters. Right? You'll know what they are in just a second. Jesse made the comment that the mandate to automate okay. I want you guys to automate the network. What does that mean? Oh, I don't know what that means. There's a new mandate that maybe is, you know, ten x or a hundred x fuzzier. I wanna use AI. We need to have an AI program. I know you're playing with some fun stuff, and let's not steal the opportunity for another episode in the future. But what have you been playing with, and what are the the useful things you're finding for AI and network operations? Sure. You know, AI has become a force multiplier for me of my my work output. Through this, you know, I've been able to learn much faster. Great example. I when I was refining the PCI tool, we'll go back to that, I was looking for a way to do big data analysis. You know, I at the time, my skills had not gotten to the point where they needed to be to scale out. So I used AI to figure out what are the libraries, what are the tools available. Sure. And you ought to identify polars and pandas and a couple other libraries. And based on my use case, it honed in on pandas. And I was able to, in a matter of a couple of days, learn how to use PANDAS for big data manipulation, big data analysis. So it became a force multiplier of learning. And I've continued that trend since then for learning new things, figuring out new concepts much, much faster, building upon the knowledge I already have. Without the previous knowledge to be able to look at what it was giving me and think critically about it, it could have been very detrimental to my success. Because, obviously, there are times where it was producing examples that just did not make sense, methodically, or in in a real world application. So it's definitely something that I'm very conscious of now when we think about AI with automation to be to be very, very safe with it. And there are some pretty cool things that I'm working on when it comes to how AI can benefit automation that'll be a little more open in the near future from myself and from the organization. Well, that's a that's a tease. Thanks for that. But that's that's a good way to get yourself invited back. The last thing I wanna tie to this, you know, again, you made a a pretty interesting statement. You can tie this to your experiments with AI or you can just completely treat it separately, but you've said that failure is your favorite teacher. Right? And not a lot of people are willing to say, I love failing. Ethan just raised his hand for audio only viewers. I've never really seen Ethan fail. How tell me more about your perspective there. How can you get teams that you work with or that you you support from the vendor side now to, like, hey. Lighten up. You can learn from failure. What does that look like for you, Jesse? Sure. You know, this was something that did not happen overnight to develop this mindset. But, you know, it actually kinda came from my grandfather and my papa. And it was a lesson that he taught me young in life that I'd never resonated till recently that we learn the best lessons when we fail. And, you know, when I look at all the coding projects, all the development projects, I try this and fail. Try this and fail. And it really started that his voice in the back of the head was, k. What can you learn from this? You know, this didn't work right. What can you learn from it? And what can you do better the next time? And I kind of have adopted that mantra. You know, you go to job a job interview. What is your greatest strength? I'm a failure. You know, instantly, the interview is taken back Yeah. With that because nobody who with their right mind is gonna tell somebody that's interviewing you for a job, I'm a failure? Well, I'm a failure because I've failed more than I've had success. You know? And anybody that's built a business, done anything successfully, you just see the want the success. You don't see the hundred tries before Yeah. That got them to that one time that it was successful. And that's that's kind of my story. I I run into this like, well, how did you get to where you are so fast and this and that? You don't see the hundreds of thousands of scripts that I wrote that failed, the ideas that failed, the all of these things that got me to where where I am today. So that's where so young engineers are organizations that try automation and fail, try and fail. It's finding just keep you gotta get keep trying. But every time you fail, you've gotta learn from it. You know, sit down, have an honest assessment. What did I do good? What did I do bad? What can I learn from it? And through those iterations, you'll get to that success. And when you have that success, it'll be much more rewarding in the long run. I don't know of a better place to wrap this up today, so much more we could say on this. Jesse, I'll just give you the last opportunity. Anything else missing or anything you wanna really emphasize from today's conversation? The only thing I could say is, well, if you're listening to this podcast and anything that I've said has resonated, I will be with the ITTRO crew out at AUTOCON four. So feel free. You come track me down. Have a conversation. That's from the time of recording, it's thirty one days away. So the clock is ticking, and, you know, we love we look forward to seeing you at AutoCon four. Jesse, really appreciate you being here on Total Network Operations today. Ethan, anything you wanna call out that particularly struck you today? Just that I agree with Jesse on failure, Scott. Raised my hand because of my experience with failure, is that if you don't fail, you don't know how why things work when they actually work. You gotta learn The loop from failure is much more effective than feedback from success. Because when you succeed, you don't know how you succeeded. You know? Maybe I just got lucky, which is probably true for me in most circumstances. So very good. Thank you to all you listeners, you operators for tuning in and listening today. We'd love your feedback and ideas on this show and future ideas for shows. Go ahead and contact me via DM on LinkedIn if you'd like, or send us a follow-up at Packet Pushers dot net slash follow-up. Thanks again, and we'll see you next time on Total Network Operations.