Speaker 1    00:00:01    Join us as we gather around the hedge, where we dig into technology, business, and culture with the finest minds in computer networking.  
Speaker 2    00:00:20    Well, hello Tom. How are you today?  
Speaker 3    00:00:22    Hey, Russ. I'm doing great. How about you?  
Speaker 2    00:00:25    I'm fine, I'm fine. Getting ready to buy some new weightlifting equipment, I think, because, I don't know, I think, I think dropping 65 pounds of weight on my chest once was enough for this week. I think maybe it's time to move to a different, to a different weightlifting process.  
Speaker 3    00:00:42    Yeah. We can't, we can't record the hedge if you've been crushed. So let's, let's do something different.  
Speaker 2    00:00:47    Better do something different. And I finished the book for the CS C S S T last week. I'm just in editing process, so that should be out sometime soon. And I'm working on something for Amazon now, which may be interesting, but it's not gonna be in our, it's not gonna be in our listeners range. It's gonna be if you have a high school student and you want them to get interested in networking, kind of a thing that I'm working on. And so, let's see, today we are joined by Mike Bouchon. Who is standing, standing, Mike, that's, that's, I don't know how many hours a day. Do you just stand? Do you stand versus how many do you sit?  
Speaker 4    00:01:23    I usually will cycle, uh, two hours standing, one hour sitting. And so I'll kind of just flip back and forth.  
Speaker 2    00:01:31    That's cool. That's good. I was doing like 15 minutes standing when I first started with the sanding desk for like every hour of sitting. And now I'm to the point that I really don't even have a chair. I just have a stool. So everything is standing or leaning now for me. Mike is in San Jose? No, no, no, no, no, no. Los Los Angeles  
Speaker 4    00:01:52    <laugh>.  
Speaker 2    00:01:54    He's covering his eyes.  
Speaker 4    00:01:57    I live in San Diego. Think, oh,  
Speaker 2    00:01:59    Ok. That's better  
Speaker 4    00:02:02    Weather. Los Angeles without any of the,  
Speaker 3    00:02:06    Did you drop the dumbbell on your head, Russ?  
Speaker 2    00:02:11    Oh my goodness. I always forget where you live, Mike. Sorry about that.  
Speaker 4    00:02:15    <laugh>. That's alright.  
Speaker 2    00:02:17    Yeah, San Diego is, is is actually a nice city. Uh, I've gone down there a couple of times for, um, for ETFs and stuff, and Cisco lives and stuff. And, you know, the, the old city district is really cool with the Ghirardelli and all the jazz restaurants and stuff like that. That's a really cool area to go to. I assume they have something other than jazz, but I don't know.  
Speaker 4    00:02:39    <laugh>, the gas lamp has all kinds of music.  
Speaker 2    00:02:43    Yeah. So that's good. So today we are talking about, well, I'm just gonna let Mike introduce it because I'm, I'm not entirely certain how to explain this, so go run with it, Mike.  
Speaker 4    00:02:52    Sure. The last time we got together, I had made a comment that, um, operations in the data center was gonna change. I think we're kind of on the cusp of wholesale changes. And this isn't even like a chat G p t kind of reaction. I mean, I, I actually said this before, a lot of the AI wave was coming on, but I think operations are changing, driven in part by changes in the workforce, uh, driven in part by adoption of cloud. You know, there's obviously things like Kubernetes. All of these things I think are conspiring, but I think we're gonna see, uh, effectively a, a, a sea change type event in data center operations. And frankly, it, it ought to impact how people think about their careers. It ought to impact how companies think about architecture and, and evaluate, you know, what they're going to deploy and how they're gonna deploy it. And it will absolutely have, you know, ramifications to the entire vendor landscape.  
Speaker 2    00:03:45    Interesting. Yeah. And let's start with a career one, because I think that is the interesting, well, let's start with describing what you think is gonna happen. So this is not tat pt, this is just, you think that the data center is gonna be more automated, more less peoples oriented. How do you think that works?  
Speaker 4    00:04:05    So I'll start with just kind of the, the real people side. You know, we have a, a, a crop of network engineers who, you know, frankly are aging out. Now, of course not. The three of us don't,  
Speaker 2    00:04:14    Don't, don't talk about me that way. <laugh>, of course not <laugh>,  
Speaker 4    00:04:17    We we're, we're timeless, um, <laugh>. But, uh, there are, let's say other folks who, who, you know, are, are less inoculated to the, um, impacts of time. And so as the network engineering group ages out, the question is, you know, what is the, the bumper crop of new network engineers look like? And I would submit to you that the bumper crop of, of new network engineers are probably not trained the same way they were before. They're probably not specialized the way they were before. They're probably not oriented the way they were before. And so that changes a bit on, on kind of what network engineering has to look like out of necessity. So, you know, the new folks who are looking at network engineering are probably not coming up with, uh, let's say a, a specialization in Cisco and having, you know, some commitment to rote memorization of, you know, a of of vendor specific c l i, they're probably coming up, you know, cutting their teeth primarily on cloud, which means that the tools with which they're familiar, the interfaces that they've established, you know, kinda a, a bit of repetition with probably more closely resemble the cloud.  
Speaker 4    00:05:21    And so as you bring that workforce in, the resulting tools that enterprises and and service providers rely on are going to naturally have to look more cloud-like, that means that the whole job of network engineering, you know, moves away from, you know, CLI first. And when that happens, I mean, like that is a, that is a big change for a lot of folks who you know today. That's primarily what they do. And if the job elevates above the c l I, then going back to the people side first, like, what does that mean to how you assess people's talent? What are you actually looking for? Um, and if that's the case, then what does that mean for, you know, certifications, demonstrating talent and intersecting with some of the job openings? Like I just think that whole space is gonna change in a, in a pretty meaningful way, uh, pretty quickly, by the way,  
Speaker 2    00:06:11    And by, and by the way, I also think this doesn't just go back to cloud. I think this goes also back to how all the current crop of network engineers cut their teeth. Where did they come from? I started in electronic engineering and came through programming. There is not a lot of people out there who work on radio stuff anymore. There's not a funnel coming from that side of the world any longer. It just doesn't exist. Coders are not detail in detail c coders any longer. The coding career field is 95% JavaScript and front end development and stuff like that. Whatever else kinds there are. The most detailed you get nowadays is people who write rust and go. And that's nowhere near near the level of detail and complexity of writing something in sea and even diving into assembly. So I just don't think the technical background is even out there for people like me or Tom or other people to come up. I just think that that's gone. You know, it's, it's like a modern engine mechanic. Oh, you just plug a thing in and it tells you what's wrong. Well, nobody ever knows how a carburetor works now, or even how fuel injection works. They just don't know. Cuz nobody's ever ripped down the ripped off the head of an engine and redone all the bits and pieces and stuff like that growing up. It just doesn't happen.  
Speaker 3    00:07:32    So how does that, how does that change the, the products that vendors offer and how we interact with them? And I think the obvious, one of the obvious things is while you'll interact with it differently, like you were saying Mike, c l i versus a p i versus other interfaces. But, um, what does it, how do, how do the, how are the products different? The vendors that I've worked with, some of them have done a very poor job of, uh, giving me a way to interact with the product in a way that would make it so I can scale my own effort. So yeah. From, from a product standpoint, what do you think that means?  
Speaker 4    00:08:02    I guess the, the first thing if to recognize is the point of interaction changes. Once the point of interaction changes. The question is like, where are you gonna put your, your effort? So let's take, you know, like a, a ui. Let's say you put a fancy gooey on the front end of something. Cause you realize that people are, they're not gonna be, you know, typing c l i command by command, device by device. So you put some centralized gooey that's gonna act as a, like an SDN controller and, and act as a single point of interaction once you put that gooey up. Um, so one, the point of interaction's different, right? Where people log into the things that they do are different. Um, and then what people tend to do is move from, you know, type, type, type to click, click, click. The, the challenge with the click, click, click model is that, um, it doesn't scale particularly well.  
Speaker 4    00:08:45    So clicking is, is actually really useful for like small scale operations. If you want to like look into something typically like a presentation layer might surface, um, but there's an issue somewhere and you might click into that to figure out, let me see a little bit what the problem is. But when you try to deploy anything at scale or do anything that requires interacting with, you know, more than just a couple of devices or more than just a couple of commands, you still need to have something that allows you to move quicker, which means you have to elevate above the gooey and into something that's more API driven. Um, that's a fully different product than something that's gooey driven, which is fully different than something that is like CLI driven. You know, when you get into something that's API driven, you have to start thinking about, you know, architecturally what information are you exposing. Um, things like API versioning really matter because consistency across releases is like really important. Um, and there's a lot of things that go into like how you design product that is, that is different and you have to account for not the the people, but the systems that are gonna be, you know, connected to your, your, you know, products. Um, that's a, again, it's a different product management discipline. Um, and like that just, that's just a starting point, by the way.  
Speaker 2    00:09:53    Yeah. Yeah. And, and, and by the way, from my perspective, good riddance to memorizing CLOs <laugh>, good riddance. We've spent far too long in our industry evaluating people's skillset based on how well they know A C L I. I mean, even I go through interviews and people are like, well, what would you configure on this particular operating system to make? What, what are the commands to make a route reflector do this? And my answer is always, if we're playing the trivia game, we can play the trivia game. Okay? Like, I can ask you questions about X 25 that you're never going to have encountered in your life or had G R P, but like, who cares? That's not the point. The point is you're not actually evaluating their skillset when you play the CLI game. And we've had an entire generation of network engineers who do nothing but memorize CLIs. And I am so like, glad if that's over. Now, it scares me that we may end up with an entire new generation of network engineers who don't understand how the network works at all because they've memorized the APIs <laugh>. But, but that's human nature, man. I mean, we love our memorization skills and we don't tend to do very much about thinking  
Speaker 4    00:11:10    This, this gets a bit to the workforce changes, right? So if, if things move away from, you know, what is the certification to demo, to demonstrate, um, capability and having memorized whatever the, the CLI is that you're going after, if that all changes, then you know, what does the workforce look like? You know, you need to have people who are better at a systems level. Um, you need the, the thing you're looking for actually is the networking side. So kinda do understand architecture that becomes a bit more of a proxy for do understand what's going on. Um, you know, we see it in cloud, right? A lot of people, the only early folks who moved to cloud, uh, they thought that they could effectively abdicate architectural responsibility for what they were doing. So they moved stuff to cloud, it was no longer their problem. And then that didn't always work out that well for, for them when there was an issue, you know, Amazon, you know, one of the regions goes down and all of a sudden you have entire companies that are like unreachable because they didn't think it through.  
Speaker 4    00:12:01    Like, you know, what do they do with availability zones and what does fail look like? You know what they realized the hard way was that, you know, the the things that matter, they still matter, right? You still have to build a design and build and understand and then, you know, not to your point about the carburetor, look, not everybody can open a carburetor, but it turns out that the people who can become very, very valuable, right? So there's gonna be this period in, you know, as you make the transition where the people who really do understand what's going on under the hood, like they have very, very valuable skills. Um, like I'll, I'll, uh, just like a basic question. Like what, what if you, what programming like, or what programming language, um, makes the most money right now? Like if you had to guess what programming language is the most lucrative? Probably  
Speaker 3    00:12:44    Cobol. Probably  
Speaker 2    00:12:45    Coball against cobal. Yeah, a  
Speaker 4    00:12:47    Hundred percent, right? It's cobol, right? Because it's a bunch of banks using a bunch of stuff. It's like, it's, it's their, it's money printing applications. The number of people who know it is like, you know, dwindling. And so those people are like, are absolutely, you know, in, in, in demand. That same dynamic is gonna happen in the networking space where you're, you're, you're, as we get more abstracted, as you move to, you know, kinda further away from the network, there's still a need to understand networking. The number of people who will really understand it is gonna be, it's gonna be dwindling. Those people will command, you know, hefty salaries. So it's gonna create this interesting dynamic where you have a relatively small number of people who really understand the discipline. You have a, um, you know, most of the jobs don't require understanding what happens in the, the networking equivalent of a carburetor.  
Speaker 4    00:13:33    Um, and so most companies won't necessarily care as much. And so people are going to figure out what do they want to, what do they want to go do? I guess the point of this is that I don't, this isn't meant to be like a, a, you know, some kind of doom and gloom scenario that everyone's gonna, you know, Hey everyone, your careers are going away. I don't think, I don't think that's true. I don't think careers are going away. Um, but I think that the, the next crop will look different than the last crop. And, and, and that split, people just need to be thoughtful about where they're going to be, which bets they wanna place. Um, you know, and,  
Speaker 2    00:14:03    And if you're younger, maybe it means don't memorize cli and no matter how much your job is pushing you to do that, or no matter how much your community is pushing you to do that, you'll actually learn how networks work and then learn how they work architecturally so that you can make architectural decisions rather than configuration decisions. Cause configuration decisions aren't gonna add value any longer. That, that seems to me the bottom.  
Speaker 3    00:14:30    So as, as, uh, people enter their workforce, or I, I guess not enter the workforce as people kind of cross the boundary between outside of a company to the inside of a company, they have to be evaluated somehow, um, by, in, in the hiring process. In, in the past, we, a a lot of large enterprises have basically outsourced that to the vendors in the form of setter certifications. Cause the vendors, they make the best certifications college Yeah.  
Speaker 4    00:14:53    And colleges  
Speaker 3    00:14:53    In a former degree. Sure, sure, sure. Yeah, yeah. So the vendors make better certifications than the, than these generic ones. They just do, the labs are better. The, the quality of the exams are better. Um, and so, so the, the question is, can we still do that? Can enterprises still sort of outsource the, uh, examination, like the evaluation of their candidates to a vendor in this new world? Is that even possible?  
Speaker 4    00:15:19    Um, that's a good question. I don't have like a great canned answer for that. Um, I think it, it maybe, I guess it depends on the environment. I just think that the things, the skills that you're looking for are slightly different. Um, I think the architectural skills, you could still push those off to architectural level certifications. I think that makes sense to me. Um, you know, obviously I work at Juniper and we've done some architectural level stuff, and I think that's still a reasonable proxy for, and do you understand networking? Um, but I think, and actually I've been counseling lots of companies lately on, you know, what do they need to look for, in my opinion, something like Terraform probably looks closer to the, to, to what becomes a widely deployed thing. And so what I'm looking for is, is skills in a different set of, of, of tools.  
Speaker 4    00:16:03    And so you could still potentially outsource depending on what, you know, those types of companies are doing in their certification landscape. Um, I'll be honest, I'm not like, you know, fully current on all the certification stuff kinda above the network. Um, so you still might be able to use other folks as a proxy, but the skills I'm looking for are quite a bit different. Um, and then you might have to look at things like hiring and pairs. Um, we see this in some of the DevOps stuff already, where you have, you know, the, the DevOps person understands the programming side of it. The, the networking person understands the workflow. And if you take somebody that understands programming and pair them with somebody who understands workflow, you get something that's useful. Um, I think you gotta be thoughtful about kinda what your job roles are, who you're gonna pair with who, and then what does that mean to hiring,  
Speaker 3    00:16:45    Hiring in pairs. That's cool. I think I, I that, I like that idea. I think we see assignment of job tasks as being in pairs a lot, but actually hiring, um, I actually can think of friends of mine that I'd like to be hired as a per, as a pair <laugh>, you know, someone who's complimentary. I can think that would be, has anybody doing that right now? Do you do that, Mike?  
Speaker 4    00:17:05    Um, so I sometimes I do that, but in different settings. Um, you know, but I'm a, I would say I'm a unicorn when it comes to the hiring side. I don't think many people hire in pairs because most people are still transactional about how they manage budget, right? So typically you're given a, a particular role. What people do is, is they take the role, they, they break that role down into a set of tasks. They take those set of tasks down and they break those down into a, a set of, um, like prerequisites. And then they go and they screen candidates for those prerequisites. I think that's, uh, like 1950s style hiring, honestly, <laugh>. Um, the, uh, I, I believe that the way you, you, the way you build great teams is you don't start with like, what are all the roles and then fill the roles.  
Speaker 4    00:17:45    Like the way you build great teams is you start with great people and then you, you figure out how do you go put those people to use. The reason I hire in pairs is what I'm looking for is some unique contribution, some breakthrough thing that somebody can do that has not been done before or elsewhere, like in my competition. And so I find people who are, you know, deep specialists in some way, like they do something that, that, you know, other people don't do, right? Um, and then what I try to do is pair those specialists with other folks who can, you know, whose job it is, is to translate rest of organization into specialists and specialists into rest of organization to navigate the process and the, the mechanics and the tooling and all of that. And so I tend to hire in pairs because I'm thinking this way naturally.  
Speaker 4    00:18:29    Um, now I may not hire explicitly like two people coincidentally, but when I hire somebody, I'm already thinking, who am I looking to pair that person up with? Um, I think that's the way, like I, it's a different approach. And so do I think people will, like legitimately in the moment interview two people on higher and pairs? I don't see that. Cause that would presume that both positions are available at the same time that you have budget and appetite to onboard two at once. But I do think you need to be thinking about, you know, kind of how do you, how do you pair people up so that you can, and then make sure that there's a, not just a, a knowledge fit, but also a kind of a culture fit so the two people can, can work together. Um, I, I do think that's a, a, a viable way to navigate this going forward.  
Speaker 2    00:19:12    Now, from a skillset perspective, do you think this pretends well more for foxes or more for hedgehog, more for specialists or more for generalists? Uh, yeah, I know you get the reference, it didn't really need to explain it, but some of our, some of our listeners are like, what <laugh>  
Speaker 4    00:19:32    Hedgehogs is a, um, is a nod to the hedgehog principle, the idea that hedgehogs do one thing and they do it one thing very, very well. And so they're very, um,  
Speaker 2    00:19:42    I think it's a Greek philosopher said the, the Fox knows many things, but the hedgehog knows one big thing or something like that. And so there's like this, I think it's Plaus or somebody, I mean, I'm a philosophy PhD, I should know that that's stupid <laugh>.  
Speaker 4    00:19:58    Um, so I, I I think one doesn't exist without the other, frankly. So I, um, if I look at, we start with DC operations. If I take DC operations, there's like a really big strategic thing that's gonna happen, right? Um, when the future of networking is protocols, right? What it's the, the center of gravity is gonna be on the vendor side usually because that's who staffed up all the I E T F bodies, and that's who's doing all the vendor, like all the protocol research. And, and so when something like Rift comes out, it's like you really are leaning on the, the vendors to try to, to navigate and guide that. And, and there's things like interop that they have to figure out. And, and, and a lot of the big brains and, and this stuff are all kind of on the better side, right?  
Speaker 4    00:20:38    When you sh shift and it becomes operations, then the center of gravity, in my opinion, shifts as well, right? Operations is less about how do you do it and more like what are the workflows and what are you trying to accomplish? And vendors have historically struggled with really understanding that, because if you're staffed with a bunch of people who've never actually built and operated stuff, then you don't, your view of operations is understood purely through interview. Tell me what your operations looks like when you observe what you do, but that's different than like actually doing it. And so when you shift to operations, what ends up happening is that you, you know, the, um, you gotta start changing, um, you know, not just what do you do, but kind of what, what are the source of ideas? You've gotta, you know, vendors need to bring more customers into their, um, product teams.  
Speaker 4    00:21:25    I don't mean like, you know, again, through interview, I mean like, you actually have to hire more people from customer side, um, who actually understand operations. And so in, in that model, the operation stuff is, that's your, your, your hedgehog, you know, potentially they may not be like a gifted product person, but they're really good at customer like operations. And then you pair them with your, with your foxes who know how to do many things, who might be like, let's say your normal product management type people who can navigate process and whatever. Um, so in that model, I, again, I, in the, in the pair model, I think you take specialists and you pair them up with, with generalists. And so you'll have, you look at an organization that's healthy, you need to have a good mix of foxes and hedgehogs. And if you're all one or all the other, I think, I think you're gonna have a hard time.  
Speaker 2    00:22:10    Yeah. And from a career perspective, I've always, it's, I mean, we make it more specialist versus generalist, but in our kids it's, by the way, it's the Greek poet archus, I don't know how to say it correctly, but there it is. Anyway, you know, we, in the original concept of hedgehog and fox, the hedgehog is somebody who has a unifying theory for everything. And the fox is somebody who doesn't have that unifying theory. And so we've kind of converted that into generalist versus specialist. But I tend to think myself that from a career perspective, you're always better off to be the hedgehog, but the hedgehog who knows everything, right? The hedgehog who has the grand unifying theory about the way things should work, but doesn't skimp on being outside of their realm, not the person who's, oh, well I just take everything and just approach it as a single, a single thing. And I never try to come up with unifying theories or understand what's actually going on, is kind of my perspective. So, but yeah, I was just curious about that because I know Mike, you know, you focus a lot on hiring people who have a lot of range and not just the, not just the really narrow specialist. So I think that that's an interesting thing. And from a career perspective, like, you know, what do you do with that? Well,  
Speaker 4    00:23:31    I think that the career folks, I mean, there, there's, there's gonna be a bet that you have to place because you can't know everything. And so the question is, where do you want to, like what do you, what do you wanna major in effectively? And some folks can, you know, can kind of take their, their solid base of, uh, networking understanding, and they can say, that's gonna be my foundation. I'm gonna stay with that, and I'm gonna look for companies that, you know, for which that's a, a, a great useful skill. And there'll be longevity in that career. Um, cuz as people, again, as people sort of age out or opt out of the whole networking space, which will be left with is a, a demand that outstrips the, the, the supply of folks that can do that for folks that are earlier in their career, I think it's a, that's a difficult thing to do.  
Speaker 4    00:24:13    It's difficult to, to manufacture, you know, 20 years of, of experience in the networking space. And so if you go in and you major in that, I think it's, it's challenging to necessarily land a job. Um, and so what you do is you have to go in and, and, you know, probably go on the other side. And I think there, the question is, do you, you know, do you focus on, you know, Cisco cert, a Juniper cert, um, you know, no certs and something else. I think there you have to be a little bit clever and, you know, if I'm being honest and like very specific, like I think that the, the value of the, of like the Cisco search, I think that, I think those value, that value goes down. I think that I, I think being good with Hashi is probably more important.  
Speaker 4    00:24:56    Um, you still gotta know the networking stuff, don't get me wrong, but you gotta understand the tools you're gonna be working with. I think that that's what happens. And if we believe that automation is real, right? And we believe, if you believe any of the Gartner stuff that says, you know, automation's roughly what, 22, 20 3% of, of normal enterprises when the ambition was that it was gonna be like 80, 90%. Um, the question is, you know, do we think that that shift is finally gonna start happening? And, and my my contention is, yeah, I think we're finally starting to see it's gonna happen, you know, driven in some way out of necessity, which, you know, typically drives a lot of these types of changes. Um, and that necessity being driven by, you know, the pandemic, the great resignation or great reshuffling, the sort of rise of cloud. Like there's a bunch of stuff conspiring all these different trends coming together that are forcing a, a reevaluation of, of what people want to do as individuals. And that's gonna force a reevaluation of what companies do to cope.  
Speaker 2    00:25:51    Well, we live in a very tech school world. We live in a world where individual skills are highly valued and generic skills theory is not valued at all, unfortunately. And I don't even know of many educational paths today that get you beyond the basic, like, how do I write a script that configures a Juniper or a Cisco router to do X? That's 90% of our education today. Just like 90% of it used to be how do you configure X on a Juniper or Cisco router? And, and now we've just moved it one slot back. And so if your vision is right, that the, that the data center is gonna move towards automation, but we don't just need people who can write scripts. We need people who can look at the whole network and say, how do I make DCI work here? What applications are running? What does the application, that application running mean for the fabric or for the network as it might happen to be? Because not all data centers have to be fabrics. I mean, that's something we've done recently too. It's all data. Go ahead. Um,  
Speaker 3    00:27:02    Sorry, I I think that's mostly a question of scale, because at the smaller scales, you don't really have to know how it works. Like you don't, you plug in a few switches, you do your thing, like you, you, you read the vendor white paper. I mean, it just to be totally honest about like, you don't really need a ton of in-depth understanding of how the carburetor works. If all you, if y all you have is one car, if you don't, but, but as you start to scale up the stuff that you're talking about, Russ, in my opinion, does start to matter a lot. And then at a certain scale, you cannot operate without understanding of how the stuff actually works. You can't even, you can't even run your business at a certain scale if you don't understand the underlying stuff. So my question is, what percentage, I don't know these figures, maybe you do, Mike, uh, uh, what percentage of business that vendors do is in stuff that is in such large scale that the, that the business could not operate if people didn't understand how stuff worked? Are most of your customers in that area or, yeah, just throwing a few switches. No big deal. You don't really need to know  
Speaker 2    00:27:51    Before Mike answer is that I'm gonna replace scale with complexity. Sure. Because, because some small networks are still very, very complex. Sure, sure. And some very, very large networks are actually very simple and you still don't need to know how they work. You just plug everything in and it just works. So, sorry, go ahead Mike.  
Speaker 4    00:28:09    No, I think that, I think that's right. Um, uh, if you look at by volume of customers, by volume of customers, obviously it's skewed to most people are doing things that are quite small. Um, I feel like at, by volume of dollars, volume of the business, most things are skewed to people who are doing things quite large. Um, a couple years ago, I, so like the SMB space was, was in decline. It was like down 80, I wanna say it was like 86% year on year because everyone's moving to cloud. Cause if you don't own your own applications, it's like just consume SaaS services. I mean, right? Like, like if you don't have anything to host, don't host anything <laugh>. Um, and so the the parts that I think the, the parts of, of the market that are, um, that are, that are, you know, so small where it's like deploy a couple of switches, you're not really making any changes.  
Speaker 4    00:29:01    Um, if you make a change, it's like a, you know, adding a VLAN because you're swapping a server out or something like that. Like, if that's the environment you're in. I, I, I agree. I don't think, I think if you're in one of those roles, you're, you're probably not a networking person. You're probably like a, you're probably the local it it person and it covers like, like all, you know, everything. You're also fixing the printers. Um, I think when you get into, you know, environments of even moderate scale and complexity, I think, I think it, it, it shifts a little bit and then I think it's a bit of a continuum from there. Um, if I look and say where the dollars going be made, both the vendor side also on the customer side, like where are the rules that above some, some complexity threshold proxy, the pro, uh, the, oh, got the proxy for <laugh>, um, which the, which accounts are, which or which, you know, environments are, which is probably less about like, what's the size of the company and more about, you know, effectively how much of their infrastructure is owned versus, you know, kind of outsourced.  
Speaker 4    00:29:59    Um, and then on the own decide, like if you're not doing anything in the application space, I think everything approximates like a SaaS service. And, and yeah, the, the, the networking component is really, you know, connecting up your sites to that, uh, still difficult networking challenges in some cases, especially with lots of distributed sites. Um, but as I started with like data center operations, the data center part of that's actually pretty, pretty straightforward.  
Speaker 2    00:30:24    Hmm. Yeah. And I, I think that's, that's becoming more and more true particularly of data centers over time that data centers are becoming, I mean, it used to be, when I first started networking data center was the hard thing to design wide area was understood. Now we're almost reversing that, again, data centers are pretty easy to understand in design and wide area is more of an art because nobody does it, right. Nobody does it anymore. Right? It's the same thing. When I first got into networking, I went out and tried to convince customers to use BGP in certain situations because they were connecting large, you know, large multi-site networks together. And they were trying to do it with O S P F or ED G R P. And it was like, no, you've got 30 sites, maybe you just need to back off and just use BGP here. And they were all scared of bgp. Oh, it's so hard. It's what providers use. And now nobody even knows O S P F or ISIS s I mean, I go to places and I say, well, you should really use ISIS s for this. We don't have anybody who's ever worked on is I s I'm like, did you do that <laugh>? That doesn't even make sense to me. <laugh>. So I think, I think that that's the kind of shift that's coming more towards automation though, than it is towards particular protocols. Probably.  
Speaker 3    00:31:45    I think that,  
Speaker 4    00:31:46    Sorry, go ahead.  
Speaker 3    00:31:48    I was just gonna say, I, I think that represents an opportunity actually that swing that you're talking about, Russ, because inevitably it happens over and over. Yeah. And the, the person that understands the principles can easily jump to the side of the pendulum that is the most, uh, profitable in, in the labor market today. The person who is just stuck on a set of things that wor happens to work on WAN devices, they can't ride the pendulum back and forth, but the person who knows the, the protocols can, sorry,  
Speaker 4    00:32:11    Mike, that's a good point. No, no, that's a good point. We talked, last time I was with you guys, we talked this idea about, you know, skills that are portable. And that's a, a good example where some of the architectural skills are actually portable to different, different models. And that portability means that there's a, it's, it's highly leveraged. So putting effort behind actually knowing what's going on, that becomes, you know, something that'll pay off regardless of which model you end up working in. I think that's, that's super bright. Um, on, on the automation side, I, I, I also think that automation's gonna open up, um, a different class of stuff. Like there's a school of thought that's like, I wanna, um, you know, I wanna provision something, I would like to automate that, or I have this simple workflow, I wanna script it. And if for people who view automation primarily as a scripted outcome, like, I think it's a pretty narrow view of automation. You know, if your primary responsibility is to, um, remove the keystrokes it takes to do something under the premise that you're gonna remove human error or speed something up, the best investment for your company would be to send everybody to a typing class, right? Because <laugh>, they would not fat finger things  
Speaker 2    00:33:18    And, and, and code reviews do better, code reviews better, better reviews of configurations. Yeah.  
Speaker 4    00:33:25    Yeah. Like, so, so it turns out the time doesn't usually accrue at the typing of commands time accrues at the handoff between organizations. And so the goal of automation isn't merely to take what was in your head and put it onto the, you know, onto the wire. What it's, it's about, you know, how do you remove some of the handoffs and friction between things? So could you codify code reviews? Could the tool, for instance, do validation? Um, I came up through the Silicon world, oddly, I don't have any real silicon background, but I came up through the, the ed a industry working at Synopsis and then magma on the, the verification side. But it turns out like when you build a chip, you spend like half your time, you know, building, like designing the chip and half your time verifying it. Yep. And there's these crazy automated test benches that have to stress it in all kinds of ways to make sure the chip, you know, behaves as expected.  
Speaker 4    00:34:14    And that takes a lot of effort. Networks probably aren't that different, right? It takes a lot of time to build a network, but then the verification of the network, and today that space doesn't, you know, normally really exist. It could be that, you know, in the automation space, what you start to see is that it's not just, you know, how do I get command from head to to device, but it's, you know, are there other things that we can do to make sure that things are gonna work as, as intended? That whole shift. Like that's a, that's a, it's a different way of thinking and it's, it's more than, you know, I'm a network engineer and I picked up some, you know, Python scripting skills, or, or I learned to go. And I think, so I think there's, there's gonna be a, a, not, not just a shift in what's the point of interaction, not just a shift in sort of the workforce, but I also think that we're gonna get into higher level things that drive a little bit more value into the organizations. And as that happens, that's gonna be yet another set of skills and things to kinda lean on.  
Speaker 2    00:35:11    Yeah. The,  
Speaker 4    00:35:13    Oh, sorry.  
Speaker 2    00:35:14    I was just gonna say, I, I, I think that one thing you hit there about verification is something we do not do in network engineering today at all. And the whole life cycle concept, I even struggle with this in my network right now. People don't really think about backup plans. They don't really think about, how do I test this? They don't really think about what to do. If it doesn't work the first time you try to test it, they don't. None of that is in there. It's, let's get the configuration on the ground, get it running, get this done, and then I can go home and go to sleep for the weekend. And I think the coding world is just starting to pick that up. But Lifecycle is one of those architectural principles that if you can learn that, that's a huge deal. Sorry, Tom, jump in.  
Speaker 3    00:36:00    Yeah, no, my mine was, uh, sort of along the similar lines. So I, um, I work on a NAS team now, uh, supporting an open nos. And it was very clear to us from the very beginning that if you were gonna deploy this, we have to test it because we don't, so we don dove straight in. I built a whole test harness, the whole, the whole environment so that we run tests every night and all that stuff. And learned a ton. And it is, it is absolutely a new domain of expertise. And there are people, I don't know if anybody's listening to this that's in that domain already, but like the testing world is a totally different way of thinking. And to me it was like super exciting and like stirred up my imagination. And, and I think we have sort of whispers in this in networking.  
Speaker 3    00:36:35    We have people talking about C I C D, like that's kind of how they approach it, is that I wanna put it into c s CD pipeline, which means I need to test it. Well, that's, that's just a hint and a shadow of what's available in the testing world. And I, you know, I think the problem is there's not a lot of appetite for it right now, because people don't see what value it can deliver. But yeah, I think that's, I'm probably, I'm just excited because I'm hearing stuff that I've, I've been learning the last couple years, but I think that there's a ton of value for that sort of thing. And people with networking skills who have learned how to write code, I mean, it's natural. It's just like, I already know how to think about this problem. It's just a different, a different, uh, scope.  
Speaker 4    00:37:09    Well, this, this opens up a whole class of things that would be possible. I, so I've wanted for years, and I've actually tried the two separate times. You know, what if there was a common test description language, so the tests themselves were portable, you could have your own test bench, right? But like the tests were portable across different boundaries. Like that would be crazy hot because then you could write your tests and then I could execute them. Um, you know, I always tell people, and this is somewhat of a provocative statement, but, um, you know, I, I, I talk to folks, so I tell 'em like, 95% of your testing is probably useless. And they look at me like, that's a pretty provocative statement. I'm like, what are the chances that you're testing something that I'm not already testing? If we were working as one company and we had perfect visibility, we would probably allocate our resources differently.  
Speaker 4    00:37:53    The reason we don't do that is that, you know, you can't trust, like there's no trust but built up between, and so like, there's all kinds of like, organizational dynamics, but if everyone was really clear what was happening, the why it was happening, how it was happening, you actually would optimize differently. The centerpiece of that could actually be something like a, you know, a, a common test harness, um, or a common test description language, which would allow some portability of effort, which would allow discrete handoffs. We get all of that, you know, kind of going back to the initial conversation, it's like, I think that the, that the next growth edge of, of operations isn't going to be merely, you know, provisioning some stuff. Like it's not, you know, Ansible version two. It's gonna be like, there's a different class of stuff that we have to go do.  
Speaker 4    00:38:37    It's going to be difference making. It's gonna be in a class of, of networks that are either sufficiently complex or sufficiently large. This kind of stuff actually matters. And I think there's gonna be a, you know, a, a relative dearth of people who are, you know, capable of operating in that environment. And that generally that's gonna create opportunity. Uh, I think it's good that, that the transition will be a little bit slow, but I think it's gonna be, you know, for all the reasons I mentioned at the top of this thing, like, I think we're gonna start seeing an acceleration of that. And as people start to look and say like, you know, what role do I play? I just think it's, it's not, it's not as simple as it was before that. It's like the roles are defined by, you know, which vendor gear is deployed?  
Speaker 4    00:39:15    Where and which certification do you have? Like I just, I think that whole space is gonna, is gonna shift. And then as a result, the class of tools that are being developed now by, on the vendor side, not just the big, you know, wrapped switch vendors, but like, even if you look in the, the startup space, all the software companies, like the class of products that's coming out now, it's pretty exciting. And if the whole generative AI thing, you know, serves as a catalyst to get a little bit further, a little bit faster, like it could be that we see a change, you know, that that's, that's only a couple years away. Like that, that to me feels like what's, what's probably gonna happen, um, that you're gonna start seeing that just, you know, some of the obstacles are gonna start falling quickly. And, and when they do, that's gonna change things like, you know, just to make it, you know, kind of full, going back to the comments begin that everything changes and there's, there'll be, um, implications everywhere.  
Speaker 4    00:40:08    Like, you know, the partner community changes at that point, right? Because build to operate, you know, transfer like that, all that's different. The managed service space, you know, changes cause the tools are all different. Mm-hmm. <affirmative> like, um, the points of d a for network, you know, become, they probably move into the c n I like into the cloud. And so the, the questions like what happens inside, even like the colos and, and the different services that are available there, like that changes. There's like, it, it, it's, it's, um, virtually nobody is gonna be untouched. Um, once all this stuff kind of rolls through.  
Speaker 2    00:40:42    Yeah. Yeah. And, and I think that, um, darn now I lost my train of thought. That's horrible when that happens. But anyway, <laugh>, I, I do think that, you know, you're talking about how the whole ecosystem and everything changes on this stuff. Oh, I remember now. There was actually a working group called BMW G in the I T F that for a while tried to standardize black box te black box testing or opaque box testing for routing protocols, which went nowhere because nobody sees the value of it. Nobody sees the value. And the other problem I note, is that a lot of times testing is done cause it's a low hanging fruit because I know how to test it, not because I actually think that's what's going to break in the network, right?  
Speaker 2    00:41:28    And that's completely the wrong approach. So you go out and you, and you, you, you work for some large scale co company and you validate that you're gonna buy these Cisco or Juniper boxes and you're gonna verify them with your own testing. As you said, Mike, it's probably the same thing those vendors have already done. That's a low hanging fruit. Like, but I can do it and say that I've done something and I'm happy actually integrating it into my environment and seeing how my applications run on top of it and seeing how my automation system works and my knock works with that and my SOC works with that. Those are things that are never done well. I think it's, they're hard <laugh>,  
Speaker 3    00:42:10    They're hard and it's specialized domain of knowledge like you to, to know how to go after the soft spots and the code. You have to know, you have to have experience testing. You have to know mm-hmm. <affirmative>, like, what's adjacent to this thing that just failed? What else can I poke at? Right. And ignore the easy stuff, which is super hard to do, <laugh>. Yeah. Because it's so satisfying when you get like a hundred test cases and they all pass and you're like, and or one of them fails and you're like, yeah, I got one. But that's not what you want. You know, there's, there's a whole, there's a whole domain of knowledge in this area.  
Speaker 4    00:42:36    Yeah. That even gets to, again, like how do people plot their careers out? I just, like, you can't look at the spaces this, you know, unit dimensional thing where it's, you know, there's a cer that sits at the top. There's so much skill, um, that, you know, everyone, the, the more we automate, the more of the kind of the toil is taken away, the more that unlocks like a bunch of other higher value stuff. And so the kind of the industry meme that automation was gonna drive all the jobs out of the, like, I just, it's just not gonna happen. That's not what's, that's not how it's gonna play out. What it's gonna do. It's gonna drive a bunch of relatively low value tasks out of, out of the, the purview of individuals. And then that's gonna raise a, a set of higher value things that are gonna be absolutely critical to operating in any kind of complexity and scale. And if you can get attached to those things, then you can punch your own ticket because the, the value that you're driving is, is far greater than having set the device up. Which, you know, frankly, the vendors probably should have done a, a better job of making that easy in the first place anyway.  
Speaker 2    00:43:37    Yeah, exactly. So, so cool. I think this is all very good conversation. I don't have a lot more to ask or add, Mike, maybe you have some big drop at the very end that you want to, uh, drop in here and say, blow our, blow our minds or something.  
Speaker 4    00:43:53    <laugh>, why you just set the bar pretty high. <laugh> you go, Mike, Mike, it's your turn you with no notice. You go ahead blows minds like, uh, I guess the, the, the net of all of this, right? If we believe that operations changes, then that's gonna create, uh, an opening for people to go and, and evaluate what they want to go do. I think there's two things I would tell you, right? If you're on the, the, let's say the aging side of the aging workforce, you know, I, I don't want people to think that it's all doom and gloom and that they're gonna be left without a career at the end of this. Because the architectural skills that you've acquired, those are valuable and to, to russ's car reader, like there's there that, that stuff matters. And, and making sure that, that you, you fine tune that stuff and hold onto it, like that actually still matters.  
Speaker 4    00:44:40    Um, it'll matter in a diminishing way over time, right? So for some sufficiently long time horizon, I think it, um, you know, I think the, the, the call for the number of folks who do that goes down, but that's gonna be sort of what happens with that side of the workforce. Anyway, on the other side, if you're just starting, I, it's just, you gotta understand where the, the proverbial puck is headed. You gotta build able to navigate where things are going. And that means, you know, taking a playbook that was run 10 years ago and that's, you're, that, that someone is coaching you on, you know, that might or might not be the best path forward for you. And so just be thoughtful about what the, what the field looks like for you. Make sure you call your own shots on, you know, where you think that we, uh, where you think things go and, and what that means for your skills acquisition.  
Speaker 4    00:45:26    Um, but the, the tools of the future are gonna be different than the tools of the past. That means the training of the, of today has to be tra training. That's, that's different than the training of yesterday. Um, and then so with that, you know, I, I would bet on tools like Hashi, I think that the Terraform is probably a good, a good proxy for what looks like the, you know, the, the, the standard. Um, I think that, you know, looking at how the, how people consume infrastructure and cloud is useful. I think understanding those tools is valuable. And then I think there's gonna be a whole set of onap space, like the whole digital twin movement is, is interesting. And as Tom points out on the testing side, I think that's a, like, there's real value that can be driven there for those that are more technically oriented and, and have a kinda a systems view of things. There's probably like real lucrative paths in that space. And then as people are putting together their company strategies, if your company's strategy is effectively more of the same, you know, good luck with that. Yeah.  
Speaker 2    00:46:23    Yeah. Pretty much things are gonna change and both for careers and for companies, if your plan is to do exactly what we've done for the last 20 years, you're probably not going gonna go anywhere. And by the way, that last 20 years includes cloud, right? We, we still think of cloud as being something branding new and exciting and, but honestly cloud's getting old now and there's bound to be something else, right? There's bound to be other things that we need to adapt to. So, so Tom, anything else?  
Speaker 4    00:46:55    Nope.  
Speaker 2    00:46:56    Okay. And where can people find you if they want to? Tom?  
Speaker 3    00:46:59    Uh, LinkedIn and, and Twitter. I don't check either of those very often, but Tom Ammond you'll find me there.  
Speaker 2    00:47:04    Okay. Awesome. And Mike, where can people find you? LinkedIn, Twitter, what else?  
Speaker 4    00:47:10    Yeah, LinkedIn and Twitter. Uh, I tried spout. I'm waiting. I'm just kind, kind of part of the dumpster fire that is Twitter right now, just to see what happens with this thing, you know? And then, uh, so, so if something else pops up that looks like it's gonna be like a good alternative, maybe they send me a note on Twitter, so I know to go  
Speaker 2    00:47:28    Is that's, that's, so, that's, yeah. That's great there. Mike <laugh>. So when I'm Russ White, you can always find me here at the hedge on Rule 11 Tech, Twitter, LinkedIn, blah, blah, blah. I'm really, really hard to find, trust me. But thank you so much for listening to this episode of The Hedge. Um, we know your attention is valuable in this crazy world where you have way too much to pay attention to and we hope we're adding value to your, to your weekly listening or whatever that you're picking up stuff that's really cool. Um, thanks for joining us and, and we will catch you next time.  
Speaker 1    00:48:06    Subscribe to the hedge on your favorite podcast service or follow along@ruleeleven.tech.