The Art of Network Engineering

Communication Fundamentals Every Engineer Needs to Master

Andy and Friends

Send us a text

Recorded on-site in Austin, Texas, at AutoCon 4 (Network Automation Forum), Andy sits down with Colin Doyle to talk about the human side of technical communication and why it matters more than ever in technical careers.

They dig into practical speaking advice for engineers: how to slow down without losing authority, why “dead air” feels scarier than it is, how to stop relying on scripts, and how to structure a talk so your audience can repeat your message when you leave the room. Colin shares the “audience-first” mindset shift: don’t tell your story, tell the audience’s story with you in it.

Then the conversation widens into the network automation adoption problem: why network automation still lags behind other IT domains, why tooling fragmentation creates anxiety (“what if I learn the wrong thing?”), and why starting with Python is often the safest first step. Colin also reframes overlays (EVPN/VXLAN) as a fundamental shift: abstraction changes operations, pushes configuration to the edge, and makes intent-based operations and assurance the real job.

If you’re a CLI lifer preparing to level up, or you’re giving your first big talk, this episode is a practical, grounding guide.

In this episode: communication fundamentals, talk prep, booth culture at AutoCon, automation adoption barriers, overlays → intent → assurance, and why you don’t need to be a “kung fu wizard” to start automating.

This episode has been sponsored by Meter. 

Go to meter.com/aone to book a demo now! 

You can support the show at the link below.

Support the show

Find everything AONE right here: https://linktr.ee/artofneteng

00:00
This is the art of network engineering,  where technology meets the human side of IT.  Whether you're scaling networks, solving problems, or shaping your career, we've got the insights, stories, and tips to keep you ahead in the ever evolving world of networking. Welcome to the Art of Network Engineering podcast. My name is Andy Lapteff, and I am in person  again with a human. This is Colin Doyle. Hi, Colin. Hi, Andy. How are you? I'm better now that you're here. You just landed. How was your flight?

00:27
It was uneventful, which considering the quality of my flights to Nandog was  welcome.  Where are we? We are in Austin, Texas. We are at the Marriott with the most  difficult elevators I've ever encountered.  We are here for Autocon4. Autocon4. A network automation conference thrown by the Network Automation Forum. The folks at NAF, Scott Robon and Chris Grundeman are the founders of that organization. This is my first Autocon. Have you been to one of these?

00:57
This will be my second Autocon and fun fact about Autocon, then this is Autocon 4, but it's actually the fifth Autocon. True to form nerds, they started at zero. indexed. I love it. Nerds, I blame Scott. Scott probably did that. Oh, I'm sure he was super excited about it. So I've been here a couple days. You just got here. I sat in a workshop yesterday with some folks from our company and learned some GNMIC awesomeness. Oh, that was Red Insajio, wasn't It was amazing. Oh, they're awesome. I sent an API call and set.

01:26
an MTU on an interface.  mean, I copy and paste it. didn't do anything, but it was amazing. the whole point, not supposed to type.  It was amazing to watch.  So I'm excited to be here is my point. I was in a workshop. The conference starts tomorrow, but there's been two days of workshops.  Earlier today, I recorded on heavy networking with the Pack of Pushers people. That was a highlight for me. like, oh my God, I got on the show, right? You get starstruck sometimes when you talk with them. Because every time I see Ethan, like...

01:52
I'm finally over it. He like told me to stop. He's like, dude, okay, enough. yes, the first probably five or 10 times I saw him and talked to him, I'm like,  it's you, you're the guy, you're the... Cause I came up listening to them. Right. was the thing. and Drew, yeah, they're awesome. So it's been really cool so far. um I don't really have any context other than a couple of days of workshops. uh What...

02:13
can I expect from the conference tomorrow? Like you've been to one. So is it just people talking all day about cool stuff and you learn things? Yeah, my highlight reel from the last AutoCon is going to come with a asterisk because I was only a few months into my time at Nokia and spent a  good deal of that time at AutoCon at the booth.  Now, it was fun. They allowed me to build and expense  a cloud chamber. So I built a portable particle detector.

02:42
And then I brought a thorium source  in the form of a tigrod. is thorium? So basically... You're in the wrong industry. I think you should be like a mad scientist. I saw the pictures in the videos of you building that pinball game. It was very... You're like next level science stuff. I bet I would be proficient in Python if I had spent my time doing that instead of doing the Arduino programming. ah It is my job though.  That when you're here at the booth...

03:08
And I don't know if this is the experience of anybody that might be listening, but I've been doing events for the better part of two decades now. And  first as staff, then as support crew, and now as an attendee,  probably 130 or so at this point. And  the  booth experience is always here's a table, maybe there's some gear, here's some swag. So much swag.

03:33
My wife has banned me from bringing things home and there is a strict one-in-one-out policy for high value swag like nice water bottles and things like that. But I'm not allowed to come back with just everything I can grab because what ends up happening is it just goes in a corner somewhere and there's just so much of it.  I  am on booth duty for the first time in my career this week. Yeah. Do you have any...  I think you're going there, but do you have any suggestions or recommendations for me on what makes a good  booth attendee?

04:01
At Autocon, think that the answer to that question is  different than it would be other places because there  is  no real overt marketing  vibe here. Now, there might be people that are with marketing that are here that disagree, but the experience I had at the first Autocon I went to was refreshing because there were demos and there were tables and booths and swag and all that, but I didn't see anybody scanning badges. The conversations were organic. And I think that that is important because something that

04:30
I've tried to address when I've been at a booth helping out or helping build the collateral content or trying to drive engagement is to bridge the gap between people that want information, but maybe don't want to have a conversation or don't want to get trucked into some sort of sales discussion, whether that's going to happen or not. I want to dispel that  pressure. And there is pressure where maybe I just want the information and I don't want that to turn into a conversation and then emails and I'm in the marketing funnel. So  that

05:00
has been that like, like if you go to RSA, like everybody's scanning badges, like I didn't see that.  And that meant at least from my experience that there were more people that felt comfortable coming up and talking. So what I would say for you tomorrow is just be available,  be friendly, be Andy. I mean, these are all natural, normal things for you.

05:20
Walk out from around the behind the booth and you know just talk to people and we'll walk around the room also like the booth area is open the whole time this isn't like Nanog where it's like a two-hour beer in gear and people are just you know speedrunning the  desks and grabbing the stuff they can grab before they get to the food and drinks it is  a Drop in have conversation. don't know the vibe here is pretty cool. I this isn't to say that it's uh Good or bad compared to others. It's just different and I think Scott's done something pretty special with Autocon That's nice to hear I haven't been to too many conferences and I won't call them out

05:49
to like cast shade, but yes, the few that I've been to, it's very much like, oh, you're here, let me scan you really quick. And I know what that means, and there's gonna be a ton of emails when I get home that I'm gonna ignore. But when you lead with the scan,  it feels kind of like, oh, you're here, let me put you in my funnel, as opposed to, hey, what's your name? What do you do?  What can I help you with? I think if you, reminds me my buddy, Tom, like if you lead with value, right? Like, what can I do for you while you're here? And oh, by the way, if you wouldn't mind, maybe toward the end of the conversation, like, hey, if I could send you more info.

06:18
I almost wonder if asking for permission toward the end of the conversation would be better as a scan. Like, hey, are you interested? Can I scan you? Because I have received uh direction or  suggestions from different people. Like, hey, we have this app. Make sure you're scanning people. I understand why.  I am in marketing. We support sales. We want to generate leads. But it's good to know the environment you're in. And if this isn't a heavy  cell marketing-led event, which it doesn't sound like it is,  I think it's important to align.

06:47
with that person or that persona, if I could be gross. Yeah, of course. I do want to ask you, you have spoken publicly a lot, I think, right? Like if you've spoken to crowds. Yeah. Okay, so I'm going to,  mostly what I do on the show is I make it about me and I learn something and other people get to learn.  Okay. I am speaking tomorrow. Yes.  I'm super calm about it and super confident. It's going to be great. Do you have any advice?

07:13
I have kind of gone round and round and I've probably pulled you through the mud, so apologies, but  I think I may have called you one day when I'm freaking out.  Sitting in a microphone talking  to basically a camera and my buddy feels much different to me  than being the first speaker after the keynote tomorrow in front of 800 people.  The stakes feel higher.  People from the company I work for are going to be there. I represent the company to some degree here.

07:43
and I don't want to let anybody down. So all the expectations are internal on me and I'm probably putting more stress on myself than I need to, but a lot of the advice I've gotten so far is like, just be authentic, just be yourself, just connect, you'll be fine. But I keep oscillating between, I have to memorize this 1200 word, you know, thing that I wrote, because this is all based on a blog I published, then I submitted it and they took it as a talk.

08:11
How do I take a blog that I wrote and present it authentically, conversationally in front of people? Because everybody's like, oh, well, it's just like the podcast. Well, it's not. But I think if I can bring my podcast vibe to it because I'm relaxed, I think it'll be better. So it's a lot of words to say, can you help me figure out how to prepare for this thing tomorrow? Yeah, a lot of people are just going to tell you to be yourself, not like there's a light switch. You should set up a table and a microphone and a chair and a camera and then

08:38
deliver it like you're doing. Set this up.  No, you know what? That would really be helpful. It would be. It would be. I might ask Scott if I can, because this would be easy for me just doing this.  There's short-term guidance and there's long-term guidance. And I'll start with the long-term guidance. The reason that this feels natural  is because you've done it so many times. Like most things in life,  the repetition breeds confidence. That confidence breeds a sense of relaxation. And that relaxation will allow you to be a better speaker. What I mean by that.

09:07
is that the tools  that you use to speak clearly and coherently  are ones that are developed and require practice. they  generally, maybe everybody has something different maybe, but for myself,  it is  slowing down my cadence to give myself time to talk and to organize my thoughts  and cutting out filler words. Nothing helped me  develop these skills more than the time I've spent editing myself.

09:35
talking in YouTube videos and podcasts. You really, in the moment, don't catch yourself doing ums and uhs and you knows and right now, right? I hear right a lot. Or like, right, right, right? It's like, right, yes! You know is mine and I hate it. It just slips in. Stop there for a second. So is that our brain just trying to bias time as we process, I think, the filler words? I believe that we feel as though gaps

10:04
in space,  just  dead air. Silence is bad.  a  space that generally gets filled with concern and anxiety. And you need to get over that.  Every time, even when I speak now, if there are times where I lose a thread and I take a longer pause, I've gone back and I've asked folks if they noticed and nobody has. Much like other things in life, you are always going to be your own worst critic.

10:31
and you're always going to be harder on yourself and you're always going to overanalyze your own delivery. Slow down, give yourself time to think. That said, slowing down means that you  use fewer words, which is also why you can't run off a script. Because if you run off a script  and you're reading something, unless you have got it down pat, and this is something that people do, but it's also another thing that they have to train to do well,  is to fit an exact amount of words into an exact amount of space and time. If you...

10:57
aren't very adept at doing that, you'll find yourself artificially speeding because you feel like that timer is getting lower and you know how much more there is to come. The first thing you need to do is figure out how much time you have and whether or not you can fit all your thoughts into it. You've probably heard me say this before,  generally in the context of training and enablement or even just generally in sales or trying to make a point. I mean, it's just communication. You don't want to try to make every point that you have. You want to pick the two or three points that are most relevant

11:27
to the audience and to  the whatever objective you're trying to reach.  And you want to make those that point for those points over and over. And they're the takeaways, the things, the two things that you want them to take away from it, right? Whenever I'm counseling  somebody on how to be an effective communicator, pick your topics  and  you don't want to, again, don't make every point, make a few, make them over and over. Don't make folks wait till the end  for a big reveal.

11:50
The most amount of attention span you're going to have is in the first three to four minutes you're talking to somebody. And I also like to give the, what's the nexus of what I'm trying to communicate. I'll say it right up front.  And then I will explain the steps that I'm going to take. If I'm spoiled for time, I'll explain, you know, here's the things we're going to talk about  and here's how it's going to reinforce that central point.  And this is part of that tattooing  of those three things over and over. come back to them over and over.  you lay it out upfront. You tell them what you're going to tell them.

12:18
I feel as though if somebody  walks out of the room  and  they can't communicate a central point that I made,  the way that I communicated it, that I probably have failed at what I've been trying to do. And I guess the repetition is going to drive that home for them. It is. Because I know a story, I've been studying story for like the past year and a half. This guy, Matthew Dix, wrote a book called Storyworthy and I've studied it like a textbook and I've done the work, but yeah.

12:42
I've read some of his books. Oh yeah, okay, cool. I love the guy, but you know, a beginning, a middle, and an end, right? I mean, there's a start and an end, and it's good to start in the middle of an action to engage people. So there's  the things that I think a lot of people know who try to do this, but my hesitation of telling them what I'm gonna tell them  is I feel like it's a flat-footed story. Hey guys, I'm Andy, and here's what I'm gonna tell you. And then launching into the story, I've lost  this moment to grab them.

13:10
Does that make sense?  right? So it does if you  are focused on  what you're telling them versus  what you want them to get out of it. So it's the difference between here's the information I'm going to communicate to you is flat and boring. So put yourself in their shoes and think to yourself, what value are they going to extract that they can apply in their own life that I'm about to communicate? And that's what you tell them. Hi, my name is Andy and

13:37
By the end of this discussion, it's my hope that you'll be better at XYZ. Explain to them what the value to them is. I like that. what you're trying to do. Yeah, that's not how I would have put it. don't want to tell. Mike Bouchon, one of our colleagues, is very good at this. You don't want to tell your story. You want to tell the audience's story with you in it. Or you want to tell your story with them in it. Somehow, you need to create a connection between

14:05
the conversation that you're having, the story that you're telling, and the lived experience of the people that are listening, and put them into it. that's what you'd want to do. You don't want to lead with emotion. Pardon me. You do want to lead with emotion and outcome. It is flat if you just come in and Ben Stein it, and you're like, today I'm going to be talking about these three topics. No, it's like.

14:27
You can build some excitement. It's just, think the example that I used with you once was this  manager who built this presentation. It was a single slide and like it all built up to this automation story. And then it ended with this big reveal of this product.  And I'm like, you're 50 minutes in. Just start and say, here's the product and here's how cool it is and here's what it does. And here's how we got there and walk back to it from the beginning. Show them upfront. You want to give them the takeaway upfront so that they know. I can see as an audience member, that being helpful because I know what I'm in for.

14:57
and I know if I'm gonna sit the whole time or if I might dip out for a beverage. They're gonna dip out for a beverage  no matter what.  And  the reason I like to do this is because this is probably just sales brain talking. I'm in a meeting, let's say 45 minutes, I'm doing a product introduction, I've got a VP, I've got two managers and managers, it may be  a manager.  That VP is out in 11 minutes, every single time,  every time. m

15:26
and they're futzing on their phone, then something looks like they got something important. They walk out of the room. They never come back. And this is just  99 times out of 100. That's the experience.  If you  don't tell your audience  what your central thesis is at the beginning, then you risk they don't hear it. And particularly in sales, which is part of the organization that we're in,  when somebody walks into the hallway and gets asked about what we were talking about.

15:54
If we haven't, we need to give the person the story. Cause if we let them make up their own, they'll either not make one up at all and they'll just say, eh and shrug and we've not made an impact or they'll make up their own story that's wrong. So we're really coaching and training our audience to tell our story for us when we leave. And that might not be strictly true, but I find that it's a good thing to point myself at when I'm trying to build a narrative. Am I communicating this clearly?

16:18
enough for somebody who's not even connected to the subject matter to be able to consume it and then explain it to somebody else. And that's also why you generally, even with highly technical concepts in those initial discussions, need to be focused on those outcomes because the outcome you can connect with. I can't tell you how this works, but I can tell you how it's going to make your life better. And all we need at that point is curiosity. And that curiosity allows us to come back in and explain in greater detail how we do the things that we do.

16:45
I think this is a great discussion and it's probably applicable to- Probably not helping you for your call, talk tomorrow. So it's totally helping me with my talk, but I'm thinking back to,  we recently had  Mike Bouchang and Scott Robon on and we were talking about the value of learning. Titans, I tell you.  We were talking about the value of being able to communicate  with the leaders in your organization, speak how they speak, understand what's important to them. And if you can't communicate your ideas in a way that resonates with them,

17:14
Yeah, what do they- You're not gonna say, oh, we should really do this cool thing. And so you kind of have me thinking that with the audience, like if I can't communicate to them why they should care, which is what you're saying. And I think I really liked that summary upfront because I thought that would be the antithesis of everything I've learned in storytelling. I gotta drop you right like a movie. I gotta drop it right into an action. We're in a car, it's moving. There's somebody screaming, what's happening? It engages your-

17:38
your adrenaline stuff, right? that's not- movie's not trying to teach you how to get out of a car chase, right? I think it's a different format because it needs to grab your attention. um They need something for the trailer.  But for you, if uh you're trying to communicate an idea, you're trying to educate, think about just at a basic level. I've got an eight-year-old, awesome kid,  and he is learning language, letters, numbers, all this.  He's eight, so he knows a lot of stuff already. But when you're learning how to write letters, you don't start-

18:07
by like with the letter E, like you have the dots on the page or like draw the line over. Okay, now draw the line over. And then by the time you're done, it's like, that's an E. It's like, no, you show the E. Like here's what the alphabet looks like.  Here are the letters. And now we're going to  learn how to write those letters. And as you write the letters, now we've got the alphabet.  So when you're really trying to teach somebody something,  you have to give them that anchor because lacking that context, they don't know where to put it in their brain. Yeah. Right? Show them. Oh, see I did it.

18:36
I call myself, get it right at the end. But show them the E is really, that's really landing with me. That makes a lot of sense. And even putting myself in the other, it's so funny how I've been an audience member for so many things and received information, but for some reason, because I'm gonna be on the other side of the table, I've almost forgotten or dismissed everything I know about what it's like to receive a good message, because for some reason, now I'm in this other mindset, but you're bringing me back to that person in the audience. Like, oh, right, of course I have to tell them,

19:05
what's about to happen so that they have context, they can know what's going on, and they can pull that throughout. The thing to take out of, you're right there with that audience experience. It's such an important piece because you were somewhat, and I don't want to misrepresent this, which is why I'm sort of moving my hands. I'm like, am I going to say this right? It felt like you had some concern about leading with the point because it felt from, maybe a thoggin' up to the right.

19:35
But if it feels disruptive, I assure you that's helpful. Something else I try to do when I talk to an audience is remember that we've got about seven to nine minutes of attention span before we have to do something somewhat disruptive. And if you've ever watched me do presentations, that's generally where I'll have an audience engagement of some sort,  or I'll have a funny slide, just something that kind of snaps people out. So if you're like worried that, this,  this really doesn't feel like the sort of thing an audience,  like this isn't the way you're supposed to do it.

20:05
Don't be too afraid of that unless it's like, I mean, some things are just terrible ideas. Like I  have done a few things where I was like,  ask a question, nobody raises their hand. That's rough. Although I do also have a favorite one, a favorite story of doing that audience participation where I tricked the audience and nobody raised their hand and that was the point.  That sounds like a Colin.  Yeah, it was super fun. It was a discussion about the  impact of group thinking, social pressure on decision making.

20:33
The point that I was making is that we feel more comfortable making decisions that when we feel that the consequences aren't going to be negative. And then we have negativity bias. So we're always 10 to one. We're going to think of the negative outcomes versus the positive. it has an outsized impact. This is just something in our industry where we're like tech, tech, tech. I'm like, feelings first, guys. Come on, settle down. If they don't trust you.

20:57
at first, then everything that comes beyond that is downstream of that. The technology is downstream of them just believing like you've got their best interests in mind.  And  the way I demonstrated it was I asked the audience to raise their, like apropos of nothing, we're gonna do some role playing, which if you're in a room full of tech people and you say the word role playing, like  everybody gets smaller, like immediately gets smaller. And I asked for volunteers to come up on the stage and nobody raised their hands.  And I said, that is the point.

21:23
I didn't give you any information. didn't tell you what was going to happen. You're looking around, you're thinking, am I going to be embarrassed? Like all the negative outcomes, you're going to take me up here. You're going to use me as the bad example. You're going to use me  as  the,  don't do what this person did.  And I could give you far more information about  what the outcome is going to be for you. And then you might raise your hand because now you're going to have the confidence of knowing I'm not going to be embarrassed in front of my peers. I'm not going to, you know, I'm going to be constructive. Actually.

21:51
Now that I see this in different light, can help contribute to what's going on. This is actually an important moment for me.  We need to make sure that our audience feels that way. Even if we're just communicating,  they need to be the subject of the story, not us,  to the extent that we can do that. We use our own stories to sort of express to them,  you can live this life too. I'm having a realization. Let me bounce this off you and see if it's true.  I think that...

22:16
Depending on the environment or the context that we're delivering a message, it kind of changes the delivery.  What I mean is I've been studying Matthew Dix  and they all go to this thing called the Moth in New York where they get up on stage and they tell stories. And there's 10 stories a night and the winner gets a prize and blah, blah. But I've watched these. So I'm studying this guy and he's a compelling storyteller and he works in business to help people tell stories and stuff. But when I watch their talks on stage, it's very...

22:45
theatrical and dropping them in and emotional. But I think I'm trying to have this,  this isn't corporate. I don't mean that to be that, but this is like a tech, it's a performance,  but I don't think it's the moth  emotion, life-changing thing that, so there's a very, there's a pivotal point in the story that I need to land  to show people the demark between  who I was or how I thought and how my cognitive biases were running.

23:13
my perception of the world, including I hate automation, leave me alone. But then something happened. And then afterwards I was someone else and now I'm embracing this and doing things. But I  don't think I need to have this,  what's the word? I almost wanted this like very emotional, like I'm realizing now that every talk isn't the same and you're gonna have to tailor it to the audience. And I don't think a room full of technical people and executives at tech companies  want my  soft New York City, the moth like.

23:42
I'm trying to pull heartstrings and get people emotionally involved. I think I can do that, I, this is, I'm seeing this in a different light and now I'm actually, my anxiety has dissipated because I think this is, I was trying to give a talk I would give somewhere else here. Yeah. Because the person I've been studying, that's how they communicate. But I've seen him do it in context with businesses, helping them communicate their stuff. And it's different. do you find that...

24:11
places you speak,  would kind of change how you would, like, you don't do the same thing everywhere, right? When I was going through the Dale Carnegie course, the- What is that? I've heard people talk about that. Similar to what you were just describing. It is essentially Toastmaster.  There's a Toastmaster stuff where it gives you a form to I've heard of Toastmasters. Is that the same thing? It's kind of like- Similar? Dale Carnegie is a teacher-led curriculum that is intended to help folks develop the skills to be effective speakers and communicators.  So,  unlike Toastmasters, which is  a-

24:42
organization that supports chapters that there's  charter and all that, but it essentially just gets people together so they can practice  talking and speaking and moth sounds a lot like that. Dale Carnegie is courseware. The first presentation that I did at Dale Carnegie was definitely a presentation, like a performance presentation, not a technical presentation. I wouldn't  do,  this is funny. Can you have both?

25:08
You can, but you don't want to undercut the seriousness of a product or service or solution that you're trying to sell  by being too  flippant with the way you deliver the material. And that can be a  serious, when I say flippant, I don't necessarily mean that I'm like, in the air and I've got  carnival noises and,  but  you want to make sure that you're still delivering  in the lane of the subject that you're

25:37
going to be talking about.  And when you're having a, doing a technical presentation or product introduction, or even like a lot of what I've done, which is just, hey, we're Nokia, we don't just make  cell phones,  we just make everything else now, but not the phones,  that I don't want to be  too dramatic about it, right? Like it's a cold Sunday morning and that's where I'm going, yeah. lifts into the air,  you know,  there's a loud click.

26:04
Precious, that's the word I was looking for. You said endearing, but it's like, it's so precious, right?  It's a little too like, come on, dude, take it easy. it's,  right. But I think that's what I've been trying to do in my preparation for tomorrow is have this endearing, precious, like, dude, take it easy. We understand that you're here to tell us something, but  this  isn't a novel. we're not, right? Like this isn't the notebook, take it easy.  You don't have enough time, I think, to...

26:34
Effectively, because I think you can do that if you have enough time to put a long tail on it and sort of ease your way back into the discussion. But my understanding is you don't have a ton of time tomorrow. So you're  going to have to pick all these 10 minutes, all these topics. And you're to have to pick the two or three that you think are the most important. You're going to have to communicate that to your audience.  She said something earlier, and before we get too far away from it, and I forget, it  dawned on me that another thing about podcasting that is different than standing in front of  the

27:00
audience that you're going to have tomorrow is that your audience for a podcast is self-select. The people that are listening are ones that are listening because of the way you deliver. They want to be there. Because of the content. And you're going to have a captive audience tomorrow, which means that you're going to have to provide more deference in the way that you present your material to that diversity of folks that you're going to have. Now, my marketing ick, personas. But there's going to be a diverse group of personas, and you're going to have to speak to all of them.

27:29
And that dramatic stuff, I'd certainly know people that would hit with. Will it hit with all of them? Not if you're trying to make a serious point, but if you're making a silly point, absolutely. And I'm thinking of Bouchang because I'm a big fan of how he presents and communicates. And he's not overly, you know,  he's amazing. He's hyper skilled at understanding what's valuable to his audience. Like that is a superpower of his. He's very concise. Yes.  He lands the points when they should. He's not,  yeah.

27:56
This is a very, this has been a very helpful conversation for me, but I think there's a lot of communication things in here that people can take away, which also ties back to other Mike episode. Do we want to tie a bow on this portion and maybe talk about something else for a little bit, or is there anything else we want to I got time.  I guess because we're here, when I do this on-site stuff, I feel like it should drive the topic. Like we were at NFD, so we talked about vendor relationships. How do you navigate vendor relationships? Because there's vendors talking to network people. like, how do you, so like we're here at Autocon. Right.

28:25
I guess we could spend a little bit of time on this if we want. Maybe it's not interesting, we'll see. But  don't build it up so much. So  this whole conference exists because network automation  is so  dismal, so lagging behind. So if you look at all the other tech stacks, think Linux servers have been automated for decades.  Automation isn't new  in tech or in industry. They've been doing it in warehouses and factories forever.

28:52
Network automation is still lagging behind. That's why NAF exists. And I think that they're trying to have these conversations of what I'm afraid of. And it's part of my talk tomorrow, but coming to conferences, hey, you like automation, I like automation too. Let me tell you what I did. And you're, oh, wow. Like everything. It's a bunch of people that are all fans of the topic that we're talking about. But I think the greater goal is how do we push the industry adoption higher? And I don't know

29:22
So the question I guess I have, and this might open it up to other things, do you think  that everyone  who agrees that network automation is great, getting together to get excited about network automation  makes any measurable difference  in the networking industry to the people like me last year who were like, I don't wanna talk to you about any of this. I think that there's a chasm between.

29:46
the tradnet ops people that like Scott Robon talks about, the CLI lifers, which is what I'm talking about on the blog I wrote, there's just two different camps.  A,  do we have to get those trad people over? I think it's important. B, do we think throwing conferences can do that? we're not, having this conference is better than not. And I'm having a great time here and I think they're doing valuable work. I just don't know if the outcome of getting

30:14
more adoption of network automation in the industry until you connect to those people who were like, hmm, hell no. No, I don't like this. I don't want to code. Python is hard, which was me last year. so I get those people. is hard. Well, right. But like networking isn't easy. like I worked, you remember Chris Marget? He was a Juniper. He told me, he's like, dude, I've seen Cisco CLI. You're telling me you had like two dozen page notebook plus plus.

30:40
You know, scripts you created in Cisco CLI to like load in routers. You're telling me Python's hard, but it does seem for some reason to brains and networking that that's just not transferable. It's not. How do we do this? It's different.  And I think that network automation  suffers in a way that application automation doesn't from a lack of cohesion in tooling  or a lack of momentum for certain tool. I mean, we have things like Python, but Python

31:09
There's a lot of these automation tools that aren't overt networking automation tools. They're just automation tools and they have networking libraries or networking use cases. you say cohesion of tools, are you talking about vendor tools? you talking about open source? talking about if we're building a modern application, we're generally going to be using Kubernetes or some sort of containerized.  Exactly. You're going to build a application that's based on containers. The application development,  like this open source or application automation has

31:39
There are just some primary tools.  are some things, there's a lane. You know where to direct your attention. I think one of the things that network automation struggles with is what do I go learn first? What's the most valuable thing for me to learn that is a network automation tool? Do I go learn SaltStack?  Is it Python? Do I need to know how Yang works before I do? There's just, it's so  heavily stratified. And even within the space,  the  tools that people are using, it's funny you had the scenario earlier, it's like you network automate, I network automate. And those two people are gonna be using

32:09
20 different tools that are completely different from each other and have the same outcome.  that's bad.  It ain't great. Right, right, right. The other side of that is that the vendors are already building tools that are attempting to bridge that automation gap. Everything that a network does is downstream of applications. So  to go back to one of your earlier questions, it's common. Like automation,  yes, you have to learn that. Everybody else has to come along. To the extent that network automation can build some consensus around

32:37
central, like these are the things that you should learn. That doesn't mean that this is like a certification body like Ymax Forum, right? I my stamp of approval on it and there's a licensing fee. don't think any goofiness like that. The thing that I think will bring folks along for the ride in a way that's meaningful is some well-defined and broadly accepted guidance on the tool sets that people should learn about that are going to be valuable to them.

33:05
Network Automation Forum provides a community of people who can put their heads together and potentially, I don't want to say recommendations because I don't think that's what NAF exists for, but I think that- if you're bringing those minds together, you could try to codify it or kind I'm not trying to nudge Scott in what NAF does in a direction, but- but that's-

33:25
That's impactful, right, to the industry. need to know. The reason that I avoided learning stuff is because of the anxiety of what if I learn the wrong thing? I spend all this time learning this thing  and I had to get drug in front of uh an M7i router before I learned Junos and I just had to do it. And then that was 20 years ago. I learned iOS before...

33:47
and learned anything else like most of the people my age did when they were in their 20s. that was tied to the hardware in front of you. You  to I was going to make money.  There was no downside to learning Cisco iOS then.  So  now, what do you learn first? From a programming standpoint, getting to the complexity of all the worksheets and stuff, it's like, you're telling me Python's difficult? At a high level, all of this stuff works the same way.

34:12
Even the programming I was doing for that game I built, it's like I have objects and I have actions. I have conditions and when those conditions are met, then I have something triggers. You had software in that? Yeah. It's like a pinball game. anybody listening probably wouldn't see it. was a really cool pinball game where it was like you're working a maintenance outage or a maintenance window and you to get the ball through the... Yeah. So where you wrote, what code did you or what program? So Arduino has their own, it runs on its own.

34:41
automation platform called IDE, and then there's libraries that load into IDE, and those libraries, much like Python or a lot of other programming languages, represent, shortcut's not the right word, but it represents environmental variables that apply to specific use cases. Is that software what made the game do the things? It is. So the game itself, for those of you watching at home, and you can see videos of it on my LinkedIn page,  there are stepper motors  at the heart of this,  and the stepper motors can go up.

35:07
they can turn clockwise or counterclockwise. And in this case, that drives a mechanism up and down on a Z axis on the left side and the right side. And there's a lot of stuff I had to wrap around that to make sure I wasn't  blowing things up, setting things on fire, over limiting the motors.  But ultimately, the libraries I loaded in were libraries that ran stepper motors. And stepper motors run based on an input that says you're going in one direction or the other, and then the number of steps. that

35:33
could be coded, or you could use a library that was already built for stepper motors, and then it's just environmental variables and some values.  So Python's the same way. And back when we were working at the old place, there were versions of Python libraries that were specific to the operating system. And I think most operating system, network operating systems are like that, except maybe SR Linux, which is just an automation stack,  masquerading as a network operating system. seems like Python is what you should learn.

36:01
Python is the most broadly adopted. And I think it's the easiest for non-programmatic, backgrounded people. There's heck of lot of out-data. It's more English-looking, right? You can find a way to learn Python the way you learn things, because it's been around for so long. It's so broadly adopted. There's something for everybody. It is a safe bet. But again, not strictly a network operating, like a network automation tool. You can apply Python to many contexts. This isn't like a...

36:30
We almost need, I mean, this might not even sound smart, but we almost need like one, like, I don't know if IEEE is even the right thing, but like a standardized, non-vendor automation language and networking that everyone can learn. I guess it's Python, nobody's gonna make a new one, but it's models. I mean, I think that what we're doing with Yang and however you feel about Yang, the fact that the configuration's model-driven and it's not.

36:59
That model isn't upstream of a CLI. The CLI is downstream of the model. The model exists. You can run the operating system without the CLI. In fact, SR Linux CLI is open source. You can go and play with it if you want to. And the data model allows you to automate things with less friction because of the way the data It provides a common structure for your automation. It also allows, and we're not,  we'll do this.  I don't think we're doing it yet, but it allows for  versioning so that,  like our

37:28
data center platform, EDA, if you build your own automation into that app store, it'll version that. And that versioning is really important because it means that if I upgrade  other elements of the orchestrator, is that  version of the automation with the model that it has, is it still going to be useful or valid with that?  It just keeps you from breaking stuff, basically. Like, oh, it's that version. Then I know that these commands will work.  New version means new features are introduced and  that  there's a compatibility.

37:58
challenge. So I don't expect every network vendor to  get to the point where they're all using a common model. There's a lot of IP.  it's going to be,  folks will run the ATM machines for as long as they can. This will, yeah. But what I do expect  is that the way that we are interacting with applications, the way the applications are being deployed means that you can't avoid network automation if you want to be in the network.

38:26
That's what I was gonna ask you earlier when you said you have to learn it. And I didn't want to interrupt you because you were in a role, but why? Because we haven't yet. And this is the persona that was me last year, right? Like, why should I? In my mind, two things. A, I was laid off and couldn't find a job for a year because every single networking job description had automation as a prerequisite. I was like, uh-oh, it's happened. I wasn't paying attention, it happened, but also improv. And I think...

38:55
the LLM AI machine learning stuff that is now popping and happening is going to be gasoline on that fire, where before it was like, you better learn automation or you're going to be out of a job. Well, now it's just that the rate of change has accelerated to the point where if you don't skill up now, I don't know how much longer you could be a network. I don't know how long you could be a network engineer without understanding any of this programmatic stuff, because that's where the industry is,  and it's heading there fast. Does that sound accurate to you? I can give you a tangible example. eh

39:24
If you look at the  way that network protocols themselves have evolved and how they started  to like, I'm talking specifically about overlay fabrics,  historically in the WAN. And when I say that overlay fabric, most people are going to think EVPN VXLAN. But really, I'm thinking about VPNs and tunnels, which  EVPN VXLAN is. VXLAN is...

39:47
a tunnel. And let me a good VPN. Give me some... Yeah. So  MPLS  out in the WAN world, been around for ages. we get this level of segmentation in the data center. And they've just done a couple of different ways. We do VPN VXLANs are relevant example most folks know. And then we see it moving into the camp. What this does effectively is we are deploying protocols in all parts of our network now that are almost entirely abstracting  the interface level configuration.

40:15
from the operator experience. All the overlays on top of the underlay, All an overlay does is it abstracts intermittent topology.  it makes the host A over here think it's  the same broadcasting main as host B if it's layer two. It's an abstraction of everything in the middle.  So we're already abstracting a lot of the network that we historically  were configuring manually. Paul's there for a second. I never thought of it that way. All the overlays have already abstracted the route switch job that we all came up.

40:45
saying was the job. what an overlay does at its heart is it takes a, let's just say it's a data center, EVPNVXLAN, and we put an overlay in there. What we've done also effectively is we've taken a network that was a collection of nodes  that each had their own perspective of what the world looked like. And we've turned that into an entity, a fabric, a single gestalt of all the elements that go into it. The reason that we do that is because...

41:13
That abstraction allows us to optimize the communications, the relationships between the services that run over that network.  So we're already moving  networks in that direction. So we don't need to learn automation because application  people are telling us we need to,  and  we're now working for them.  No. We're doing it because the networks themselves are changing. And in doing so, it's allowing us to shift focus  to the...

41:42
thing that networks exist  for in the first place. And that is the assurance that the relationship that we define between workloads  is going to be maintained. And that starts with  that abstraction  of the underlying topology and building tunnels over the top for those relationships. And then  it goes to intent, where  I am not  using the source of truth  as the configuration running on a node in a data center. And then

42:11
collecting that information from each node and then like a magic eye painting, blurring my eyes until I see the boat. And it's like, OK, right, now I know. Intent shifts the source of truth to  the orchestrator. And the orchestrator  is  now checking what that entity, that overlay entity in the data center, that fabric  is configured for and making sure that it's behaving.

42:36
I was just going to ask you, what does that get us?  Is that the assurance part you said earlier? It's making sure the network is doing what it should. It is making sure it's doing what it should, not because I know that this interface is configured, but because the services that run over the top of the network  are configured properly based on... Because when I explained whether you're designing a legacy data center...

43:00
whether you're designing a new one that has a fabric, the first two steps are always the same. And that is define the services that are going to be in the data center and define the relationship between the services. And then everything else comes after that.  Now, if I'm in a legacy data center, my next step is to take that relationship between services and start getting very precise about what switch, what rack, what switch port. Does it go into a routing instance? And from there, I can start to develop the device-specific, the node-specific configurations.

43:27
If I am  in an intent-based system that abstracts that configuration into the configuration of the overlay, then I take that high-level design, that relationship between those services,  and all I need to do at that point is just feed it resources. You say, okay, well, I can tell you where the services are, and I can tell you where those services connect to the fabric, because  the services use the fabric, they're not part of the fabric. So I know where the ingress point is.  Aside from that, you just need to know what needs to talk to what.

43:57
and everything else it configures for you.  So we're already automating.  The network itself, the types of networks we deploy have changed. That's why we need to evolve. I'm not going to let anybody touch the CLI in a data center that's running an overlay and an underlay, because that's not how that works.  I need to worry about my  VXLan tunnel endpoints, my VTAPs. oh The applications, where they connect, that edge port is where

44:25
All the action happens and everything else in the fabric  is just  a distributed control plane. It's just the brain. It's just the shared information, right? It's not  single nodes that have their own perspective of routing and forwarding.  EVPN is a distributed control plane so that every single participating device in the fabric has the same view of the network. So does the majority of the networking industry not know everything you just said, which is why they're refusing to learn network automation and why NAF exists?  You're right, and it's brilliant.

44:55
But why is there so much resistance? I don't know that other folks share my perspective on what overlays mean in a networking standpoint. think a lot of people still treat them like protocols, like expanding tree or SPF or something like that. I like how you framed it. I hadn't really thought about It's just another protocol, and it's just another way of doing things. And I was like, hey, no, the fabric is a transformative way of doing things, so much so that it's now made its way into campus networks, which also to be

45:25
eyes on the audience. Vendors love that too, because if you put campus in your fabric in your campus, then  somebody gets to sell you a more expensive Trident-based switch versus a Marvell-based switch or something like that. So vendors love fabrics in the campus too.  it  is segmentation, right? It is just segmentation.  And  that segmentation

45:48
usually is couched as a security tool, but really what it is  is a way of changing your relationship with how you're doing service delivery so that it isn't a manual process. It is just at the edge ports and not  every piece of the network in between those edge ports. And every piece of the network, that is where a CLI jockeys used to be, where we're using programs like CSSHX or other SSH emulators where I could log into  20 things at the same time, and then I could basically type in all of them at the same time, the same command fig and hit enter.

46:17
And what a fabric does is it says, nope, just the edge ports. Everything in the middle, you don't touch it. It's just the edge ports. So that's a huge evolution. But if you don't see it that way,  you might think it's just the next thing. And I'm like, no,  that right there is  something that directly supports network automation. And it's also why we need to encourage folks  to  learn network automation. I think the best way to do that, coming back to the question you asked,  is this really

46:47
Is NAF  the right way? Are we doing the thing here?  To the extent that we're able to build consensus around the types of tools folks should use  to get started.  There's always going to be extra stuff out there,  customizations and unique cool tools that might have a very specific use case. But if there's like three or four tools that...

47:07
Everybody sort of agrees, yeah, this is the stuff. Learn this language, use this tool for your IPAM, use this for network device management, or if you're doing intent as a terraform, what are the things?  That level of guidance, think, would be huge. Because I think that a lot Is that a governing body? I'm sorry to interrupt you. Who would even-  You mentioned IEEE, they wouldn't. If it doesn't carry an electrical current, they don't Somebody, do we have an organizational body that could take that  on and say, guys, these are the- Maybe NAF. Yeah, yeah, yeah.

47:35
Like one doesn't exist, like IEEE or ITF or like all those.  Well, and it's also kind of a third rail because you can't say that one thing's good without potentially people thinking, well, it's like, well, my baby's not ugly.  Why not?  it needs to be- Then all the vendors start fighting, right? Well, let the vendors fight. We're talking about  by and large open source tools.  I think a lot of folks too, when we say automation, we're talking about uh non-commercial products.

47:59
Because commercial products in the automation space are almost always an effort to abstract that automation for the use case and make the operator experience  require less enablement, less training, and also sell professional services and get annuity revenue off the subscriptions.  But what Autocon, I feel, is focused on is the open source tools that people can leverage to great effect. And this is something I mentioned booth duty, but what you can expect to see if you're going into sessions at Autocon is very much

48:28
the Nanog-esque format of here's the problem that we had, here's how we solve the problem, here's the tools we used to solve the problem, and here's the problems these tools can solve for you,  which I think is outstanding.  They also do have some full forensic information  on some surveys that they do about what are the tools you're using. And that's as close as I've seen to building consensus around the tools that people should learn first  is just that survey where

48:55
folks are, you know, there's a lot of people using Netbox and here's how many people are  automating with salt.  So I don't know that Autocon needs to make a change. I don't want anybody to hear what I'm saying and think that I'm here and not happy and supportive. And I think Scott's doing great. I think that it's still early enough on that it stands to be seen,  like how folks can best be brought into this.  And I think the real turning point is the workshops. I think that those are really helpful. think  that the more new members who are just getting into automation that we see coming here.

49:25
versus old school wonks that are kung fu wizards. Tell you another reason. If you're a network person, you want to learn automation, one of the reasons you need to do it is because if you don't, then application people are going to start learning networking.  And  that's how you're going to be out of a job. You know what's interesting? Because the more our networks abstract the network experience,  the  more accessible it becomes to the application folks. I met a guy, John, here. And he's a dev. He's been coding his whole life. And he's here to learn networking. Yeah.

49:54
Yeah, just a lot less to learn.  Well, right. I had a wonderful guy. I've been talking to him every day here. And we had this discussion. I said, as a developer, I'm guessing it's much easier for you to learn networking than it is for me as a old school networker trying to learn all the development stuff. And he's nodding his head. And his company is, that's why he's here. Like, hey man, go and learn what you can about networking and how we can automate.  I mean, they're automating and all that, but yes, I think.

50:23
Not only are vendors trying to abstract complexity away enough that we don't need CLI jockeys, for lack of a better term,  or as much of them,  but there's also companies out there that like, well, we can probably teach our devs  networking, or at least enough to... I mean, the phone guys did, right? When networking first came around, the first people that were managing the networks, as basic as they were, were the people that were running the POTS lines,  the phone guys.

50:47
And was like, look, kind of  that phone switch looks like a network switch. And that's how Juniper started, right? They built routers that you could actually switch uh data and voiceover.  And that was  kind of the entry into the market space, where these routers  allowed you to combine these  technologies and these concepts. And I wouldn't be freaking out if I was in the network industry right now about  needing to learn automation, because it is something you don't.

51:16
What you don't need to be, and this is actually very important, you don't have to be an expert either. Chris Tripp, who is a galaxy brain  hyperscaler guy at our company, was talking with me about how little automation he knows. And he's showing me this Python stuff. And I'm like, that's pretty awesome. But  you don't have to be a kung fu wizard to be a very effective network automation person. And also, much like the pinball thing, it's not pinball, but it's a ball.  don't want these little Isn't there a ball?

51:42
Yeah, but I don't want people to think they're slippers.  But the thing that I did is most of what you're going to end up doing is reusing somebody else's work almost entirely and then making small changes for your use case.  And it does work.  And  what I want to dispel  is the concern that if you don't know, if you're  not an expert at it and it doesn't work on the first go, you won't be able to figure it out. Not true.  You can totally fumble your way through network automation and be effective at it and seem like an absolute wizard.

52:11
with some basic stuff. just watch a few videos online or hit a workshop or something and have that light bulb moment where you write some code and you hit enter and it's like, oh my goodness, what did you push? You a Gnmi thing? Yeah, it was amazing. And I had an oh my gosh moment last year when I used Python to run a show version over to a router with Netmeco. I'm like, oh my God, because I realized that was wrong. I'm like, oh, this isn't.

52:40
I was treating it like it was,  I don't know, quantum  physics, right? Cause that's how it felt to me. I'm like, oh, this isn't, if you spend enough time, like we do hard things, we learn hard things. Networking isn't necessarily easy, right? I had a hell of a time  with my CCNA and subnetting and all that fun stuff. If we can learn all that, I know we can learn the basics of Python, let's say. And I did, but that was only after decades of,  can't. Like if you believe you can't or you won't or you shouldn't or you don't need to, why?

53:08
would your brain tell you to go take action on it? But being out of work  and looking at job descriptions and seeing automation everywhere as a requirement, that pulled me out of my like,  oh, OK. They're not lying. This is important, huh? Because if I'm a company hiring a network person,  one can understand Python fundamentals, which isn't a ton, a huge left, like you said, and one cannot. Why would you pick some with less skills when you need to automate so that you can?

53:35
I've said it a hundred times, but at the old company I was at, had 600 switches. had to update an SNME community string on. It's one line of code that you have to put in. Would have taken me forever without my buddy who wrote a Python script for me. And we did it in three nights just to be safe. We could have done it in one. Would have taken me weeks if not months to log into 600 devices and show run, pipe whatever, do the thing, show run, look at the log, log out, do the next one. It have been awful.

54:04
You have to be excited about doing things faster too. eh And I think that there might be some folks out there who've been doing it a certain way, and that's just the way that it's done. And it's job security. Lord knows I've worked in sled  and healthcare and  some of these industries where  there's a lot of entrenched technology, a lot of  torque that is holding things in place for fear that...

54:28
any little jostling will cause the whole thing to fall down, which over enough time will absolutely happen. It's amazing to me  going into hospitals and having people say you can't upgrade switches because stuff will go down. I'm like, if there's not two  network interfaces on that piece of network of connected equipment, it is not designed to be highly available.  So  I don't know why we're having this conversation. Somebody did not want to pay for the redundancy that.

54:50
would build resiliency. Whole different episode, right? Yep. Oh my goodness, those conversations are fun though. Colin, this has been fantastic. I think we're about at the hour. You poor guy haven't eaten yet. You just got off a plane, so I think I should let you off the hook here. has been fantastic. you have anything else you want to talk about? Do we have an event to go to tonight? Yeah, we're supposed to be there now. We should go. All right, we're going to go have food and drinks and talk to people. Thank you so much for being here, Colin. Colin, thank you so much for being here.

55:19
For all things, Art of Network Engineering, you can check out our Linktree at linktree forward slash art of net-eng. We have a Discord server with thousands of folks in there called, It's All About the Journey.  We have our podcast, we have our YouTube channel, we have all the things. uh Check us out. Thank you so much  for listening, for watching, and we'll catch you next time on the Art of Network Engineering podcast.  Hey folks,  if you like what you heard today, please subscribe to our podcast and your favorite pod catcher.

55:47
You can find us on socials at Art of NetEng, and you can visit linktree.com slash artofneteng for links to all of our content, including the A1 merch store and our virtual community on Discord called It's All About the Journey. You can see our pretty faces on our YouTube channel named the Art of Network Engineering. That's youtube.com forward slash artofneteng. Thanks for listening.


Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.

The Hedge Artwork

The Hedge

Russ White
Heavy Networking Artwork

Heavy Networking

Packet Pushers
Your Undivided Attention Artwork

Your Undivided Attention

The Center for Humane Technology, Tristan Harris, Daniel Barcay and Aza Raskin
Cables2Clouds Artwork

Cables2Clouds

Cables2Clouds
Tech Field Day Podcast Artwork

Tech Field Day Podcast

Tech Field Day