
LIU022: Chris Grundemann – From Pulling Cable to Network Automation Forum
About this episode
Get every episode summarized
Each time The Everything Feed - All Packet Pushers Pods publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
Hosts & guests
Transcript ready
964 searchable segments. Every word is indexed and playable.
Full transcript
The Everything Feed - All Packet Pushers Pods — LIU022: Chris Grundemann – From Pulling Cable to Network Automation Forum. Machine-transcribed; use the interactive transcript above to jump the player to any line.
Most IT teams are managing networks stitched together from years of acquisitions and vendor contracts and nobody's accountable when something breaks. Meteor delivers the complete network, hardware, software and services delivered as a predictable subscription. Upgrade credits, a fully managed install and deployment and 24-7 support make the transition easy. Companies like Lyft, Mr. Beast and Bridgewater have already made the switch. Go to meter.com slash L.I.U. to book a demo now. That's M-E-T-E-R dot com slash L.I.U. to book a demo. Welcome to Life in Uptime, the show where we talk with the people behind the networks that keep our world connected. I'm Kevin, joined by Alexis and every week we sit down with engineers, leaders and builders in tech to uncover the stories behind their careers.
How they started, what they've learned and where they're headed next. Our goal is simple to help you see how far tech can take you no matter where you start from. Alright guys, today was that. Every time, I don't know if y'all have been with us since the start, I would love to do a comparison of Kevin's intro from like episode 1 to, I think this was episode 2, 23. It's crazy. Anyways, we have a very exciting guest for y'all today. One of our dear friends, Chris. Now Chris has had a myriad of different roles in IT. Everything from you are pulling cable, I believe, to start. And now he runs his own technology consulting company and is the co-founder of the network automation forum. So Chris, welcome to the show. Hi, thanks for having me on. I'm excited. Absolutely. Now, could you walk us through?
I'd like to start with NAF or network automation for number one. It's top of mind for me because I was just at y'all's event. But two, I feel like programmability is such a big topic today in the industry. Yeah, definitely. So the network automation forum is an organization that Scott Robon and I started about three years ago. And it's exactly what it sounds like. It's a forum for network automation. And forum meaning like a salon, like a watering hole, like a drinking fountain. It's a place to come and talk. And the organization itself, our main purpose right now anyway is to hold the AutoCon series of events. As you said, you just came and spoke at AutoCon 5, which was actually the sixth AutoCon, because of course we indexed to zero, which was a Munich this spring. And yeah, it's been amazing. It's just been this kind of wildfire that blew up. I like to say that I think Scott and I, we started a campfire in the dark.
And as the light washed out, we're like, oh, there's all these people standing out here in the dark. And they've kind of come and gathered around because it's just been an enormous response, right? I mean, like 340 people show up at the first one. And then, you know, now we're pushing 7,800 people showing up every time, three years later. This was definitely a group of people that wanted to get together and talk, yeah? Yeah. Which I mean, kudos to you for starting something like that. I feel like sometimes having the courage to put yourself out there first to bring people together is always scary, especially around something as, I mean, it seems complicated to me. That work out of me. I was never really big in programmability, like learning, learning anything related to computer science or software engineering. Like every time I open a terminal, I'm like, am I going to break it? Where does the sun I call and going? And so taking something like that and applying it to infrastructure, at least for me, seems
very intimidating. Yeah, absolutely. I think that's been part of the resistance. One of the things we set out to do, we kind of set the theme of the first event was, why haven't we seen full adoption of network automation yet? And I think you're touching on one of the answers there, right? Which is, you're taking two very complex fields, right? So networking, obviously, there's a ton that goes on, there's tons of protocols, then there's all these vendor differences and network differences. There's different types of networks with different types of protocols, with different types of vendors and it gets really, really complicated really fast. And then you add in software development, it's systems engineering on top of that. And you say, you know, here, go have fun. And of course, people are intimidated and of course, people need to come together and kind of share those war stories, both for comfort and confidence, but also to move the industry forward. And I love the idea of a forum or what you said about bringing people together because I think that's something, especially in a highly technical role, just being able to share
documentation with each other. And it goes a little bit deeper, or maybe you need, I guess, a safer place to do it than write it or get hot or some of these other forms where you find people asking questions, you know, having a Slack community like you guys do where people can put in questions, search what other people are saying or have answered in the past is super valuable, especially when sometimes you're running into problems that seem fairly niche or are very niche. Absolutely. I mean, it is, right? I mean, like I think network automation is kind of a niche of a niche in a lot of ways. If you look at a broader digital infrastructure or computer science or kind of two big balloons, but then you're coming down to where those two actually cross. And I think it is a pretty small target. And so there is a small group of people who are really working on this across the world and giving them a place to actually meet others because that's another part of it too, because it's not just asking the questions, but just knowing that you're not alone. When you're the only network automation engineer at a big company, it can feel really isolating
and really lonely. And you can feel completely crazy sometimes because not everyone wants to go along with what you're trying to push. And then you come to Munich or we're going to go to Tucson in November and you meet other people who are in the exact same position and you're like, okay, I'm not insane. I actually know what I'm talking about. And I was reminded by that because of other people who are seeing the world the same way. And that's really helpful, I think as well. You mentioned that being in the terminal and trying to figure out programming is one of the obstacles. What are the other obstacles you're seeing why it hasn't been more grossly adopted? Yeah. I mean, there's a number of things I think on the enterprise side, right? Like IT in general is a cost center for most businesses and it's just not looked at as a place of growth or innovation. And so I think there's a little bit of a bare minimum, just from a company perspective, right? They're not really looking to, and I'm speaking with a broad brochure, right? I mean, those companies that are really pushing the envelope and doing a great job. But a lot of enterprises aren't investing in training their engineers for the next new thing. They're not interested in spending quote unquote extra money on something that's already
working. And so you see some resistance just from that kind of financial aspect, I guess. There's definitely some cultural things around just kind of how things are done and how we see ourselves. And I think some of that leads into identity, which is that for a long time, we've really conflated CLI proficiency with network engineering mastery and then separating those two things out is an identity challenge, right? If I've seen myself as the person who can jump into the CLI on the device and figure this problem out, and then you say, well, actually, we don't want you to use the CLI anymore, that can be really scary on an individual level, right? So I think there's lots of reasons kind of at the corporate level, at that, you know, team level at the individual level that lead to the resistance. Now, the one thing I will say is most of the resistance at this point, I don't think is actually technical. Like there are the tools, there are the protocols, there are the methodologies like we know how to do this. Technically, it's all the other stuff that's really hard, which is often the case, I think. Are you seeing AI? Sorry. Are you seeing AI?
Have you asked the same question? Oh, okay. I'm asking again. Are you seeing that AI has helped bridge that technical gap at all? Yes, and no. I think in some ways, it's very helpful. I think in some ways it blurs some lines. I think that absolutely, right, I think one of the kind of challenges of network automation adoption has been exactly what Alexis was saying earlier. I'm in the same boat. One of the reasons I ended up in network engineering was because I didn't want to write code, right? I didn't want to go into computer science. Yeah. I was like, eh, that looks too much. That's crazy. Yeah. Wait, that's crazy that you ended up in the position you're in now. Right. Yeah. I mean, well, I mean, it comes full circle and there is some maturity involved in stuff, but what I do think like a lot of network engineers to stay on that point just for a second, really, while they're willing to maybe learn of vendor CLI or multiple vendor CLIs, like Python is a bridge too far. Well, now, if I can go to your LLM of choice and I don't need to actually know,
the intricacies of Python, but I can spit out a script that kind of does what I needed to. That definitely lowers the bar. That definitely bends the branch lower to deal some quotes from other folks, right? It makes it a little easier to do some of these things. Now, whether or not you're doing it well, if you're using an LLM and don't really know the language, like there's lots of questions around all this stuff, but I do think it does make this more accessible at the very least you can play with in a lab and learn about how Python works or go or whatever you want to do, right? And play with some of these tools a little more, even if it's answerable or something else, you can get some of that information from the LLM in a way that's very interactive and easy to use, right? The other side of the coin, I think, is that some of the hype around AI can be overblown where I think there's some people who think that AI can just magically solve their problems when, if they don't have documentation and they add AI, they still don't have documentation. Right? You still have garbage in garbage out. I mean, AI can spit out a script, but do you trust it? It's the script and I have to push it into fraud.
Right. So, yeah, so that's, I say, it's kind of a double-edged sword. I think absolutely. And I think part of the AI question is, I don't know that we know what that actually looks like yet. I think we're in the middle, I think, of a pretty big transition. So I think, you know, five years from now, AI is going to be absolutely super, super helpful in this realm. Right now, it's both, right? If you're using it well, it's great, but you could also cause bigger problems with it. Just like automation, I guess, there's just another form of automation in my mind. I wonder, I guess especially when you're pushing code into production on a network level. To give you guys a bit of background, I was just around call earlier and we were talking about, um, megaport acquired a bare metal company, right? And one of the use cases that they're seeing a lot of is they have AI agents that are continuously testing for CICD, right? They'll go, they will make code improvements. They will deploy their own compute instance on our bare metal form by themselves, make
sure it works and then push the change into prod. So if we're looking at that from an infrastructure perspective or from a network perspective, can you take something like a forward networks where it is, what's the term for what they do? It's like, digital twin, yeah, a digital twin, right? Where you have a digital twin of your environment, you have an AI agent or an instance where you can go and take a snippet of code from AI, deploy it in your digital twin to make sure nothing breaks and the change is actually doing what you want it to before you actually apply it to production. And that's where I think, yes, I think I think, you know, there's some industry level maturity needed. I think some people are way ahead on this, obviously, and some people behind, but I think absolutely, um, AI, elements in particular, but AI more generally has the potential and is acting on that potential right now to really vastly make a lot of things a lot better in this realm, right? So, so your point, right, even just spinning up that lab environment, whether you're using
forward or somewhere else, like being able to build that lab environment out becomes a lot easier with you working with some agents or you working with an LM, then just you by yourself, right? And then writing those tests, right? If you're going to do unit tests or even functional tests, like you can write a lot more tests with AI, then you can by yourself in a shorter amount of time, which makes it easier to do some of this validation that you're going to do before you push config. So there are definitely ways of use, right? That AI can make this safer and faster. Um, it's just, like I said, I just worry about, you know, just saying, hey, slap AI on it to work. It is, it's probably bad advice. 100%. So Chris, how you mentioned earlier that you did not like coding. How did you end up in this world? Yeah. Um, so my, uh, I do it you earlier. I kind of started out by pulling cable and then kind of fell forward through a couple of jobs and I ended up working for a small wireless internet service writer. Um, this was like the turn of the century, which is just a phrase I like using.
Um, and at the turn of the century, you're in Colorado anyway, right? There was like, at this point, right, early 2000s, there was, um, you know, DSL and I think even cable internet, like in the city. But if you went outside the city at all, uh, there was none. It was like either put in the like the six foot, use net dish or deal with dial up that might work, right? And so what this company was doing, which a bunch of whispers this time did was kind of push using wireless internet out to these folks. Um, and as you kind of interested, I'm going to, I'm going to answer question. I, I, I eventually I promise. But, you know, what they were doing is like pulling T1s into somebody's house. Whoever lived on the highest hill in a neighborhood, it would pull a T1 into that person's house and then throw like a rubber made tub full of gear under their deck and then put, you know, an omnidirectional antenna up on the roof and they were using, um, basically Wi-Fi, uh, it was this thing. I think it was called Carl net, which actually like all third Wi-Fi a little bit. But basically it was proprietary Wi-Fi. It was being used for fixed broadband. And so then they would put, you know, and 10 on anybody else's house who wanted service.
And so it's a very kind of shoe strength thing. It was pushing the envelope a little bit. And when I came on board, we were building, we, we ended up building our own router OS basically, which sounds a lot more grandiose than it is. Um, we basically had a bunch of pearl scripts that ran on a Linux box when it booted up and installed a bunch of IP tables like static routes and that rules that kind of created the route routing infrastructure for that ISP. So I kind of started building networking with software, um, but also in that process. So I did learn a lot of like that. I wasn't get at the time. It was, it was subversion. It was SVN. We were using, but I learned kind of like basic Linux administration skills. I learned basic coding skills, especially like version control and how to work on code bases with other people and all that stuff. But I definitely also knew that like writing pearl was not my passion, right? Um, and so like I love, I, I'm really, really glad that I got that kind of grounding in that really kind of software development and systems engineer world.
Um, but I also knew that like the networking part was more exciting to me. And I think it's just the rules based nature of it, right? Like routing protocols are pretty cool because they work a certain way and there's not really another way to do it. I mean, you get into like, the undersea lies and stuff there is, right? But, but you know, BGP kind of works the same way every time no matter what. It's very deterministic. It's very rules based. And I think I kind of naturally liked that. I could troubleshoot that. Um, whereas like a software program can break in so many ways. Um, now I really like coding, um, but I definitely like resistive for a very long time. Where now were you resisting it while you were doing the Pearl scripts and everything like this Whispool? Um, not really. I mean, at that point, like that was, you know, me being the sole technical person at the company with like 2000 subscribers. So it was much more of like, I'm trying not to incinerate myself. So I was just doing whatever. Like I didn't have a lot of thought about what I didn't, didn't like. I was answering, you know, customer support calls while hanging up a thousand foot antenna while the back of my mind like designing the next generation of the network. Right. So, um, I didn't have a lot of time to think about it.
Um, but I did gravitate towards like more pure networking from there. I started thinking into like, you know, I read a bunch of RFCs and I learned, um, about that, you know, that way and then kind of studied some of the CCNA stuff and got my CCNA. Um, but then found out about Juniper and Junos looked a lot more like Linux. And so I really kind of went down that path pretty hard after that. Um, but I just, I, I enjoyed working in the confines of the CLI. I think better than I did with the blank page of coding to some degree. Hmm. And so from the, the ISP, uh, you said you got into Junos. Do you, did you work for the company that had Junos or? Yeah. So what happened is that business has a lot of like small businesses does. It's kind of a roller coaster. Eventually it got to a point where like the guy owned the company, owed me enough money that I was like, I probably time to leave. Um, and I found a job to have a small ISP. Yeah. Exactly. Um, so I jumped over to this company that at the time was called Bertela. They were eventually bought their part of, um, NTT now kind of like, but they were basically an MSP. And they were running a Junos backbone basically.
It was actually kind of wild because they were actually running a Junos backbone, like an MPLS backbone between Juniper routers that was built over GRE tunnels. Cause they didn't actually have a backbone. So they were buying like, like just, you know, internet access at all the data centers they were in. And then building GRE tunnels between their pops to create their backbone and then running MPLS over the top of that. On the early. Yeah. That was the exposure to Juniper and Junos. And at that time, were you doing program, ability still or had you abandoned that? You were a straight network engineer at this point. That was pretty much straight network engineering at that point. Oh, yeah. How did you come back there? Like you left the dark side. You got out of programmability. You got back into network engineering, the pure, the pure network engineering, the good stuff. And then you got back into programming. Yeah. Yeah. Well, so I mean, it's a long arc there, right? We're talking about probably 20 years, but I think to consolidate it down a little bit, a couple of things happened. One, somewhere during those 20 years, my like youthful idealism was, I don't want to say like shattered.
But I came to realize that the right thing technically isn't always the right thing. And then basically got a business view of the world, I think. Right. So diving into that just a little bit, I got really into like the mechanics and the politics behind the internet itself, right? Like the regional industry and I can and that kind of stuff, which led me down the road of like, Hey, why isn't everyone using IPv6? And I became kind of one of the like IPv6 evangelists in the world. I was like, you know, literally ended up with a job where part of my job was to fly around the world and tell people to use IPv6. And after doing that for years, like banging my head against that wall and like knowing it was the right thing to do, but seeing most people just completely ignore it. I, you know, that hard question of like why I finally answered it. They're like, oh, people do things, you know, because they get paid to whether it's an individual or a company like, and I don't want to be too cynical about it, but like companies spend money where they're going to make money and people go work, where they're going to make money. And and like that was like a big revelation to me because like before that, I was just doing things that I thought were right the whole time.
Luckily people were paying me. You're full. Yeah. Um, I think that that's part of it, right? So starting to look at things from the business perspective, I started to like widen my perspective a little bit outside of kind of my little screen to look at the kind of the bigger picture. And it became very obvious that, you know, the networks we were dealing with at that time needed automation. Now, and I say that, but like, the automation piece never really left, right? So Bertella was very, very well documented. And and this is where I think I kind of think they're like observability and documentation are huge parts of network automation. And so and those pieces were kind of consistent. I was lucky enough to work at Bertella where they had this really, really good system. They were an MSP that said yes to everything. And so every single customer was a one off. But the way that their designers design things and then documented those designs and those design choices and then the configurations that resulted from that in engineering, when you were working in the knock, you could pull all that information up and see what this network looks like, what these devices are meant for, why these choices were made, all that stuff, right?
And that level of documentation and knowledge available to the knock, while it wasn't necessarily automation, having that repository there made our job a lot easier. And then I went to TW Telecom, or which was time-warning to like on the time. And they had kind of done similar thing where they were actually using my SQL database, all the configs, all the firmware versions, all the part numbers, all serial numbers, everything was in this my SQL database. And so it wasn't a digital twin by any stretch of the imagination, but I could script against this database in order to make this happen in the network. And that was probably actually where some of the stuff came back where we were working on a big network. It was the third largest metriot net network in the country at the time behind like AT&T and an MCI. And you know, doing things manually sucked. You could do it. But during the time I was there, we went from a team of eight being like the top tier ops end group that was doing all the main windows, we worked down to like three people because we automated everything.
That's amazing. With Pearl and Bash mostly and some expect scripts. Yeah. And so if you were a network engineer today and your company had no automation, right, or conversely, if you were a software engineer and you were looking for a job and you wanted to get an networking, what would you do? What would your first step be? Well, those are two very different things, I think. Taking them step in your favorite, start with your favorite ones. Yeah. So if I'm the network engineer who's working out a company with no automation, I mean, it depends, right? And scale is a factor here, right? The bigger the organization, the more I want to like actually like go get buy in. But I mean, I say that, but maybe not. I mean, I don't know. I think day one, like figure out how to make your life easier. And I think one of the best ways to start with automation in a scenario like that where you're kind of the only one doing it, either because you're the only one who works there or because no one else cares is read only automation, right? So use automation to build your observability to build your documentation.
I do a lot of work still to this day, right, with writing little scripts, they can pull information off the network and parse it out. Look for config variability, right? Look for inconsistencies and the way things are configured across devices, just even just pulling it down to have an offbox record, right? So you can start there and then, you know, you use that to show the people around you like, hey, this is what you can do with this and kind of build it up and build up confidence, both in yourself and your own skills. But then also in the organizational confidence in automation at all. Yeah, really. I'm kind of done. This is going to work. Yeah. And then once you've done all the read only stuff and you've got a really good like documentation setup, then you can start thinking about like making change of the network using automation. Potentially, which you may never even need to do, right? There are definitely networks that are small enough and don't change enough to like maybe config. You know, automated config generation is not ever needed where you're at. There's a lot of cases that follow into that that doesn't mean you shouldn't be using automation though. There's lots of other use cases for automation besides just changing configs. And I think getting involved in the community to figure out where other people are using it and networks in a similar size could give you some ideas if you're stock.
Yeah, obviously I missed a plug opportunity there. If you're in the situation, obviously join the next black, obviously join the next black come to autocon. Yeah. No. So Chris, before before network engineering, what was your first role in tech? Or did you just naturally land in your wisp? Yeah. No. I mean, I think like a lot of folks in tech, I definitely had kind of a computer adjacent upbringing, right? Like my dad, my dad, I text instruments, computer, probably in the 80s. I think I learned like a lot of math and like reading. My mom was also awesome at like reading books, so I'm teaching a stuff. But I learned a lot from the computer itself and learned how to write basic like really young. And that was on, we didn't have AOL, we had prodigy. But so it kind of had like computers in the house and things like that, right? Like kind of typical middle class upbringing of the 80s and 90s. And that was always there and I was always interested in stuff. I took stuff apart. I don't know if I ever put it back together, but you know, that was always kind of there. And then, but then yeah, later, I mean, I later on kind of fell back into it, right?
I ended up, I didn't go to college. And so I was out like, I was working landscaping jobs. I ended up working at a concrete plant that had where I was doing like PLC programming, which was kind of neat, basically like telling robots what to do in the concrete factory. And ended up working at a job where I was basically pulling cable. So this was during the housing boom of the 90s, I guess, late 90s or 2000s in Colorado. And so we were doing low voltage cable. So I was pulling speaker wire and cable to television wire and also ethernet cables inside people's houses. And and then, you know, Mike, I still kind of thought of myself as it being tech forward. And so then I led really quickly to like, oh, I can also configure the router that goes on the end of this kind of thing. And through a series of like unfortunate events where like a company I was working for kind of went out of business. And then another one did the same thing. I ended up being spotted by this guy who we were working alongside. It was running this way. And he pulled me over. And that was kind of like, he kind of gave me a break, basically. He saw the work habits I had.
And at that time, I was pulling, I was doing like dish network installs, right? So for the fifth company of this, we're doing like the one to punch it. We got to a neighborhood and be like, hey, we can get you, you know, cable television through dish network. And we get you internet through hometown access. And the addition of the addition stall company blew up. And the guy on the list was like, hey, want to come, you know, work for me. And like I said, right after that, he fired all of his technical staff, which was 50% of that was his son. And then I kind of like, you know, just had to figure it all out. Yeah. I think I think it's so interesting because I'll tell people all the time and they're like, oh, I don't have, I have a non technical background. I'm working at a restaurant. I want to get into technology. I don't really know where to start. And a lot of generic advice like take a certification, right? Go take a certification, study for a certification. Sure. And that is great advice. I think you'll learn a lot of things may be coming from a non technical background of idea, a little bit intimidating. But pulling cable, I mean, especially with the amount of data centers that are going in today, they need hands on
installers. And it's a really, really easy way to get your foot in the door to field and have hands on experience. You might not be configuring anything to start, but you would learn so much on the back end of how things are set up and what's going into a project like that while you're studying. Yeah, absolutely. I totally agree. And I don't want to propose certifications at all. Like I definitely certifications were one of kind of the backbones of my career, for sure. Definitely just even just from an organizing learning perspective, right? It was like, oh, I don't know what I don't know. And the certification gives me something to shoot for. Now I have a set of things to go learn. And it gives me kind of this goal oriented way to learn. I really like certifications for that. But I have talked to a lot of hiring managers recently who are saying, hey, one of the problems we're seeing is people are coming in with multiple certifications, but no experience. And that's hard too. And so I agree with you. Like I mean, finding ways to get practical experience, I think is really important. And like you said, I was doing basically construction work, right?
I mean, when I was doing like low voltage wiring, I was walking around with like a tool belt in houses that were being built on job sites like pulling cable. Like it wasn't a very technical looking job at all. It wasn't very technical at all. But it was kind of closer to technology. And at the time, I wasn't necessarily trying to get into technology. I was just trying to be able to buy diapers and food and gas in the same week, right? I mean, I was just trying to like, trying to scrape by and get ahead at that time of my life. But I think if you're intentionally about, if you're intentionally trying to get into technology, there are a lot of these like corollaries where you can, you know, do something that's close to what they're doing and kind of get exposure to it. And if you're doing that while you're doing thisifications, now you have some practical knowledge of like, maybe you haven't even done it, but you've seen them do it. Or you know, you can get some some osmosis learning there by being near the engineering team, right? The other one aside from like straight up like cable pulling, which is definitely something that I think works. There's a lot of like kind of like semi physical jobs like you said around data centers and outside plant in general,
like fiber splicing and that kind of stuff out in the field. There's some other areas like that that kind of feel a little bit more like construction and technology, but are definitely a gateway drug, so to speak. There's that where a lot of people came up is through because I'm kind of like help desk or knock which now there, you might need some experience, but you know, like the frontline help desk, a lot of that's just opening tickets when somebody calls. You're not actually solving any problems. And so like if you're kind of coming from more of that restaurant background or maybe customer service is more your thing, then outside labor, maybe a help desk job somewhere would make sense. Yeah. People also don't correlate is that if you, even if you're in a tech adjacent job like pulling cable, you also meet people who are in the field you want to get into. And like you mentioned, and I've talked about it before, Alex has talked about it. Most jobs that you get are from referrals or from knowing people in the industry. And so even if you're pulling cable, there might be a network admin who's installing switches as you're pulling cable, you get to talk into it a little bit.
He knows you do good job. You know, like next time you're doing for a job application, he sees your name. That's might not be all it takes, you know, it's just that correlation. Or just being able to talk to people that you meet, like if you're in the building and installing something and being friendly enough to strike up a conversation and actually talk and figure out what's going to be like. Yeah. Like harder for some of us. Yeah. Yeah. 100% 100% and I do want to underline that point, right? I think that I think because I think it's more true now than ever in this kind of current climate of big tech layoffs and AI screening systems and just like just everything is going on. Like the best advice I have for anybody if you want a job like know somebody who works there. And of course you had to have done that a year or two years before you try to get the job. Is the practical advice? Do not bring that into the messages. Right. Yeah. I know them. Yeah. Yeah. Although I did one time do the reverse network move, which was actually when that was kind of the writing was on the wall that
that was going to go, you know, wasn't going to make it and we weren't going to get paychecks anymore. I was like, okay, I need a job right away. And I knew no one. And what I ended up doing, I don't know if this is advice or not, you take it with a grain of salt. I found a company that was hiring and I figured out, you know, just from what I found online. And to like that company's email addresses had a certain format. And so I emailed my resume instead of to the application, I emailed my resume to the CTO. And he did what any responsible person would do. He passed it on to the hiring manager. Now all the sudden, I had a kind of not real, but tacit recommendation from the CTO. And I got an interview. I don't know if I would have otherwise. Here's something most IT leaders know, but rarely say out loud. The legacy network model is showing cracks. You've got five vendors with none of them accountable to each other. Renewal cycles tracked on spreadsheets and an IT team spending cycles, managing infrastructure instead of moving the business forward. The problem isn't that no one wants to fix it.
It's the switching can feel risky and overwhelming. Eater was built to solve exactly that. It's a full stack network with hardware. They designed themselves firmware, software support all in one. They support the migration, offer upgrade credits for existing gear. And the financing is flexible. Companies like Lyft, Mr. Beast and Bridgewater have already made the switch. If your team is ready to stop managing a patchwork network and start enabling the business, go to meter.com slash L.I.U. That's M-E-T-E-R dot com slash L.I.U. to book a demo. Yeah, I don't know if that's good advice or not, but it was the thing I did. And I just kind of highlight in the point that that was the only job I've ever gotten where I didn't know somebody who already worked there. And I kind of teed at it, right? So I definitely want to underline like, you know, meeting people, knowing people, like being nice is super handy for this kind of thing. Yeah, I think that could backfire. Like, it's a single email out to CTO, the higher manager could backfire if that person is very much like,
oh, you got to do it the right way. You know, I might like to call this qualify you. So just like he said, like for the, you know, grand assault experience, my point was just that like knowing somebody is the best thing. If you can build that network and, you know, which ties into, I did that semi-unknowingly, right? Like for a couple of years, like I funded my own travel to Nanog, the North American Air coverage group meetings. Once I heard what I found out about Nanog, I was like, I got to be in this room. And I like, mapped out a credit card, like sending myself to Nanog when I was way too junior that like no one was going to, no one else was going to send me to this conference, right? Yeah. But 100% those relationships have fueled my entire career since then. Again, not advice like don't max out credit cards going on trips. But like getting in the room and meeting people, I think is the best thing you can do for your career. So to your role and all the way back, right? Having that tech adjacent job puts you in the room with those people while you're getting paid to be there. You know, no credit card matching required.
I think the other thing, I've given similar recommendations before. If you need to get around HR, I mean, LinkedIn's a great tool. I feel like most people have updated LinkedIn profiles. If you can find someone that works at the company and don't just send them a message and say, Hey, I applied to your company. Can you chat nine times out of 10? They're not going to answer. But if you put together a very thoughtful message about, hey, I saw you had an open role. I've already applied to it. It looks like it might be on your team. You work in a similar position at this company. I've got a very specific niche question for you about it. And I think you can answer it. Would you be willing to hop on the phone for 15 minutes? Ask them about it. Ask if there's anyone else on the team you could meet. You could round rob in your way through that entire team and then everyone knows you. So even if you don't get that one role that's open, the odds of them referring you when another one comes open. I'm like, oh, yeah, that one guy that took time to talk to every single engineer on my team. He's a good candidate.
We all liked him. Yeah. I mean, I think along those lines, right? Like I think definitely another thing that's kind of helped my career anyway. And so I think, you know, all good advice, autobiographical, because otherwise, how would I know it works? But, you know, building your kind of portfolio, right? Like I definitely, and it's even more possible now than ever. But I started a blog really early on and kind of wrote about my certification journey and like things I was learning and things like that. And, you know, not everyone has the social stamina to like make those calls, like to be like, you know, to be reaching out cold. And be like, hey, can I talk to you about something? I don't know. I think I could have done one years ago. But what I could do was blog about stuff I knew about. And I think people noticed that as well. It's a little bit more passive. It's a little bit slower probably. But I think, you know, there are different ways depending on, you know, your tolerance for putting yourself out there to define ways to kind of make these connections and grow that, that, you know, that experience influence, I guess. I don't know what you call it.
What your friends? Yeah, for sure. Like I, so I'm actually in a hiring managing position now. And anything that a candidate does outside of their nine to five shows that need that they actually like what they do and that they're passionate about it. Right. And that kind of stuff. So like, if it's even if it's blogging or talking about and making videos or making just posts on LinkedIn about learning in public or whatever, that tells me they actually care about technology. They're not just looking for a paycheck and anything, even if that might not be true. Just just putting it out there, you know, it gives that impression. So anything you can do extra outside of your nine to five just showing up, you know, is a positive. So learning public 100%. Yeah. And just on that note, a little bit like going on that, you know, I've had barely or, you know, kind of overcome fairly bad social anxiety through the course of my life. I still don't love like introducing myself to somebody at all. But what I found was, you know, a couple of things. Right. One, again, kind of going back to the conference thing or already events in general.
If I knew one person going out and just standing next to them, I ended up meeting a lot of people without having to really go myself out there. Um, also like another piece of that is I found that like volunteering, right for like the program committee or whatever might be a one of these organizations. Like so Nanog is a big volunteer organization. There's a bunch of others, right. The Internet society has like chapters all over the world. There's a few of these organizations where you can pretty easily like step up and show interest and get on a committee or something and meet people who are also working. And it's this is this kind of to me, for me anyway, it's much lower stakes. Like I'm not walking up to a random person at a party and like introducing myself on a Zoom call where we're talking about how do we, you know, make this event better or is this speaker a good speaker. Whatever there is now there's a reason to talk and and that's where I built a lot of relationships where it was a lot easier for me to do without having to like put my heart on the platter. Well, I think you're also to me. And this is any relationship.
This isn't even just like professional relationships, like even just friendships. You need some commonality, your common goal. And I think when you're working on a project committee, when you're working on a team, when you're trying to take a new certification and you have a shared goal that you're both pursuing. Like it just gives you an easier way to relate to someone without making up conversation. Like how's the weather? All right. You're from Chicago, me too. It's your favorite sports team. Really good at that. And probably already in sales and not looking at it at all. Exactly. I mean, probably. But I mean, that is one of the cool things about these conferences because you have all these people who are interested in the same thing, ish, all joined together. So you automatically have that in common already. So like at a nano auger, Cisco live or whatever you can go. You can walk up someone and say, Oh, what are you guys running in your environment? You know, and it missed like you can talk about just shop and you automatically have that in common already. So I think it's going to these careers, going to these like places that these like people congregate, even if you're young in your career.
It's easier to do that than for at least for me running up to like, I are walking up to like a party, a person at a party and being like, Hey, how are you? You know, the small talk crap, which I hate, I hate small talk. But I can talk about technology. Like it's it's completely different thing. So it's intimidating. Yes, it's scary. Yes. But someone who's, you know, new into technology can still benefit a lot from going to these conferences and just talking to people at the happy hour or talking to people at the, you know, at the end of a session. You know, but that was really cool session. Does that like you could just start off a conversation about work. And I mean, it's a little easier personally. Absolutely. I agree. Yeah. It gives you like a buffer. Yeah, exactly. It's the social buffer. So Chris, you do technology consulting now. How long have you been working for yourself? Yeah. So working for myself, I guess now it's almost six years, five or six years.
Yeah, which is pretty awesome. Actually, even just thinking that you need about that is kind of cool. For me, that was always, well, I was going to say it was always a goal. I don't know if my like random dreaming about working for myself could count as a goal for most of those years. But it definitely was something that like, you know, I wanted to have at some point. And so it's been really cool to have that actually like happen and be working so far for a few years, right? And like one of the nice things I think about working for myself, which this may be a delusion, but I'm always kind of like, well, you know, it doesn't work out. I could always just go get a job. Like worst case scenario, I have to get a job, which helps me to take some of the pressure off because it is a wild ride, right? Like it does change the dynamics of work pretty completely, I think. And it was like, no, do you feel like you work more or work less? At first, I definitely worked a lot more.
Well, I don't know that's true. I've always worked a lot like I've always really kind of thrown everything I had into whatever I was doing. I've had, you know, at least a full time job plus one or two volunteer positions for for 20 years. And then almost always like a side project. So I kept working the same amount at least at first. You just find new things to fill your time with. Yeah, exactly. But I'm right now working on like actually requesting that a little bit and kind of dying it back. And like thinking about like, like how much do I actually have to work? What do I like? What do I actually provide value? Maybe it's a midlife crisis thing. I don't know, but I definitely got to look into that. But wait, wait, do I need to be in front of my computer for 60, 70 hours a week every week? I'm pretty sure the answer is no. And I'm working really hard to not do that. But again, that's it's kind of like another phase, right? Of the career, I definitely, I wouldn't trade the 20 years that I spent 60 hours in front of a computer. I wouldn't be where I am by hadn't done that.
But I definitely, it's feels pretty cool to be at a point where I'm like thinking about, okay, how do I actually reduce the amount of time I work without reducing the value on providing? It's like not smizing almost like your dollars per hour. Like if you're being very intentional with your time, are you actually working on things that move the needle versus just working? Yeah. And I think that practice is one that, you know, I also do, I do a little bit of coaching for a couple of folks. And that's something that we work on a lot with my coaching clients is really looking at this, right? Like so many of us focus on being busy. I think luckily, I think I have done a pretty good job of not doing that. Actually, like the work I was doing was mostly moving the needle. Obviously a lot of it was superfluous, right? There's a lot of spinning wheels. But like working to figure out where that is. I think even within the constraints of a job, there are, I think the reason I was able to do those volunteer positions on top of working the job was because I probably wasn't doing everything in that job that somebody else might have done.
That makes sense. And again, I don't know where, like, just anecdotes begins and advice. But like the 80-20 rule, like, what's the 20% of work I can do to get the 80% output, the good enough output. Like, I've always kind of looked for that. And I've always been pretty good at naturally finding that. And I think that helps with the self-employment for sure. But even in like jobs, like knowing that like sometimes you don't have to respond to that email. And no one's gonna ever notice. Sometimes you don't have to reply to that email. And no one's gonna ever notice. You know, and so again, I don't know. I'm not advocating people to be lazy, but I think like paying attention to like where you're producing value, what's the thing that you do really well, what's the thing that you have to be doing versus somebody's slacking you in the middle of the night. Like, you know, that actually something you need to do to deal with right now or not. Vera. Yeah. I think figuring out that boundary, like for me, I'm like one of the people who I want to respond to everything. I want to be on top of everything.
And so if I get an email at, you know, 4 o'clock on a Friday, I want to respond to it. I want to dig into it, figure out what they're asking for. And then I send it out and they don't get a response back because they've already left. They send it out right before they left. They're like, I'm out. I'm done. But I'm sitting there at the computer at, you know, 6 o'clock on a Friday night, working because of that. And so it's a hard thing for me to put boundaries to around that and being like, you know, the people that I'm emailing are done. So I need to put that same boundary around myself and only put an effort where that effort's going to be productive. And that's really hard to figure out that boundary of what is actually worth my time and effort first, not. It's really, really hard. I think, yeah, you said what I was trying to say much better than I did, I think. And that's definitely the key, right? For me, that's been a big part of it is, is learning that I don't have, like, that I was holding myself to the way higher standard than anybody else was. And not that I standarded it bad, but that's how you burn out. And I've definitely, I've burned myself out at least two or three times.
I, you know, depending on how you define burnout, like I've definitely crashed hard a couple of times. And my standards are also the reason why you got to where you are. And it's funny. I was going to say that I'm getting flamed or I got flamed like two weeks ago. I posted a post about, um, what was it? Something like burnout isn't real. Like I, by all traditional standards, I am burnt out. I'm tired. I'm so tired. I've been working 60, 70 hour weeks as long as I can remember. Saturday, Sundays don't mean anything. But also I feel like when I'm working on things that are actually aligned to my goals, it doesn't feel like work. Like, yeah. Like it all just kind of feels like part of life because it's something I actually give it about. And if you're truly, the burnout comes from the random on your to-do list that like doesn't move the needle or is all like random admin work. And you're trying to coordinate with people that,
kind of like you said, aren't responding to your emails or your work as contingent on other people doing their job. And then you just end up with all of this frustration. But when things are flowing, when you feel like you're getting things done, I feel like no matter how hard you work, like you feel good about what you're creating. Yeah. I think that's really, really smart. I totally agree that burnout is not necessarily related to the amount of hours you're working or how many days off you take. It's much more related to where you're at, like emotionally and psychologically within that, to to your point. Right? If you're doing things you don't want to be doing, but you don't believe in, or do you outright think you're wrong, you know, that's where burnout happens. Right? Whereas if you're only working on things you want to work on, it's hard to even call it work anymore. Yeah. 100% I can go to the different side. I do still, I mean, you still need to like have some balance in there, which I know you do, right? But like, and also, I'm also getting older,
so these things become more important, right? I think some of the advice of like, you know, when like older people give advice to you and people are like, oh, well, you need to like, you need to sleep and you need to exercise. Well, no, you do old man. When I was young, I didn't have to do any of those things. I didn't sleep that much. I didn't eat that well. I didn't exercise that much. I did fine. Now I have to do those things, right? I do think if I had done more of that earlier, I would have been more productive. But, oh yeah. That's a good point. Is almost working too much and too hard counterproductive at a certain point? I think 100% it is. I think for sure. Now, how much is too much is, I think, again, very personal, right? How much is too much has definitely changed throughout my life. I think, you know, one of the things I definitely try to look at now is kind of look at my life much more holistically. Because I think before another reason why I was able to work so hard and get so much done and do multiple projects at the same time, I'm really good at compartmentalizing. Like when I'm doing this thing, this thing is the whole world.
And then when I'm doing this thing, this thing is the whole world. But what that leads to is, okay, I'm going through a divorce and I'm moving across state lines. And I'm also working. And I don't necessarily relate those three things. They're like, oh, wait a minute. These are all three things that are taxing me. And I look at, oh, I can handle this one. And I can handle this one. And I can handle this one. Yeah. You know, like, oh, yeah, I can just keep working 60 hours a week. Why, why wouldn't I be able to? Oh, because your dog died last week. And maybe you need to take, you know, like, there's, I think, you know, at least for me, that's always been hard. It's like looking kind of, zooming out and being like, okay, wait a minute. If I'm going to be going to my sister's wedding, maybe I shouldn't take on this project right now. And I never even thought that was even an option for most of my life, right? Yeah. You can just think no. Yeah. But when you're in that, like, I mean, I'm very much the same way where like, I can just focus and nothing exists outside of what I'm doing. And what I've noticed as I got an older is that my body keeps the score still. Like, even though I'm just focusing on this one project, you know,
I'm more tired. I don't, I don't, not as productive. I don't focus as well. Like, I'm just, my body can tell that it's stressed out by all the other 10 things that is going on that I'm not currently thinking about. But my body definitely knows it's happening. And so you still have to be, be aware of that anxiety and that that stress and all that stuff that's happening on your body. And it's very difficult. Absolutely. Absolutely. Yeah. And most of the stuff you can only stuff down for so long, right? Eventually. And I think that's where like, at least for me, these my definite, definitely definition to burn out is when like, I finally got to the point where like, that I could just, it all crumbled because I had just been stuck in all this stuff down just LA or not top. And like, I'm then just kind of eventually called the part, right? It's not just working too much. It's working too much in like ignoring all the other signals. Yep, exactly. Uh-huh. Man. I know that laugh. And you know what? You probably have to do it at least once. Damn it. Just another episode where we bring someone on the podcast.
And I end up getting advice that I need to hear. Thanks Chris. Oh. No, no comment. No. I feel attacked. You can't say something. Yeah. Say something. I'm giving up on you. Uh-huh. That help. Yeah. Um, so Chris, as we wrap up the episode, if you were going to give yourself advice, a younger version of you, either one that wasn't into technology yet or the Chris who was just starting his career. What would you say? Oh, wow. Um, that's a really good question. I think, I'm going to answer it completely. Like, not, this is a non-answer, I guess. But one of the things that I have come to realize, like the more experience I've gained, the more years I've lived, is like how certain anything is.
I think when I was younger, I really, really like just like really believe the things I believed. And like I really like, and I'm not trying to say that there's no such thing as right and wrong. But like the lines between a lot of this stuff are way blur than we think they are. And so like, like again, not just holding stuff to a higher standard, but like, I was like painting myself into boxes because of these like beliefs I picked up that I just thought were really black and white. And like I had this like high-heavy certainty on these certain things. And like we're getting fights with people because they didn't agree with what I agreed in. And then all of that. And I think honestly, like the best advice I could get myself is like, no one actually knows. And reality isn't. And like maybe just chill out a little bit. I love that. I love that. So Chris, if someone wants to catch up with you after the podcast, where can they find you? Yeah, most active on LinkedIn these days. Or come join the the Nafslack. I'm on there all the time as well. Yeah, Nafslack is pop in. I'm in it myself. Cool. All right, guys, well, that is it for this episode of Life in Uptime.
Huge thanks to Chris for sharing his journey and thanks to you for listening. If you enjoyed this conversation, be sure to follow the show so you never miss an episode. And if Chris's story today gave you something to think about, share it with a friend or a colleague who might need it. And until next time, keep learning, keep building, and keep your uptime high.
More episodes
More from The Everything Feed - All Packet Pushers Pods

TNO072: Connectivity and Community with Jason Gintert
The Everything Feed - All Packet Pushers Pods

HN841: HPE Melds Apstra and Mist for Self-Driving Data Center Networks (Sponsore...
The Everything Feed - All Packet Pushers Pods

D2DO312: Networking at Scale: AWS Transit Gateway War Stories
The Everything Feed - All Packet Pushers Pods

PP125: News Roundup—Cyberattack Impacts Pacemakers, OpenAI Publishes Eye-Opening...
The Everything Feed - All Packet Pushers Pods