The journey from network to cloud engineer - a career evolution

Phil Gervasi: It's been interesting to me over the last few years, to listen to people's journey through their own career in networking, especially as I reflect on my own. And really how I find it so common to hear about a cloud engineer, a cloud engineer today, who only a few years ago was a very traditional network engineer. Now, I've always been interested in people's journeys in technology probably because my own seems to have these distinct periods that I think are kind of punctuated by events and decisions that cause me to move onto something new. And that's what we'll be discussing today. So with me is Shean Leigon, an experienced network engineer of many, many years, turned cloud engineer. And we'll be talking about his journey in the networking field, what brought him to where he is today, but also how his experience serving in the United States Air Force impacted him professionally. Something I'm looking forward to hearing about very much. My name is Phil Gervasi and this is Telemetry Now. Hey Shean, it is really great to have you, thanks for joining today, much appreciated. I'm really looking forward to talking to you especially about your journey from being a, I don't know, I guess you can call it a more traditional network engineer into what you do now, just because I hear it so often these days. So really great to have you. And Doug, always great to have you joining us, our Resident Director of Internet Analysis Extraordinaire. I'm going to add that on as well. Just getting to know you more over the past year and a half, working at Kentik. I'm going to say extraordinaire is not even sufficient. But in any case, going back to you Shean, can you give us a little bit of background of where you started in technology and then maybe what you're doing these days?

Shean Leigon: Sure, yeah. I kind of had a cheat code of starting through the Air Force, so I didn't know that much about computers. Ended up wanting to kind of join the military to go do something different in life, and found a job description that sounded cool. Anyway, I went after that, I was in the Air Force for about six years and then ended up kind of coming out working in the defense contract industry, specifically around some network engineering, system engineering type of roles, those types of things. And then kind of made my way from there over to large enterprise, more kind of the standard private sector of large enterprise. Today, I'm at Juniper Networks, so I do product management within Juniper Networks and kind of our cloud and data center team.

Phil Gervasi: Okay, great. And then Doug, I know that you and Shean know each other from your time serving together in the US Air Force, correct?

Doug: Yeah. So this is kind of one of those weird things of reconnecting with someone that you knew many lifetimes ago, it feels. So Shean mentioned being in the Air Force and I think his first assignment was in Aviano Air Base in Italy. And so I was his flight commander, I was his commanding officer. Now we're contemporaries in the industry, but in those days I was maybe 24, he's 19 or something. I got to be his boss's boss, whatever. But yeah, Shean was working on tactical telephone switches. I remember, 3865s for people in the military, knowing all this old green equipment that fits in the transit cases, you throw on the back of a truck. And yeah, I remember Shean and it was really neat to come across his name later on, I don't know, maybe in the last 10 years I think we connected. I was like, " Is that the same guy?" And I was like, "Yeah." I'm like, " Oh man, we're in the same business now." It's super fun. It's super fun to see another person that you knew as a young person, and then see them again having a lot of success. It's great to re- get- to- know- you, Shean.

Shean Leigon: Yeah, thanks Doug. No, likewise. It's definitely been fun from boy, a couple of manhawks ago we had the opportunity in San Francisco to kind of meet up and go grab dinner and catch up and so forth. So yeah, multiple times since then. Yeah, it's been great.

Phil Gervasi: So Shean, what do you a project or rather, yeah, product manager for specifically at Juniper? What's the line?

Shean Leigon: Yeah, good question. So I work predominantly in our CN, it's called CN2. It's basically cloud native networking solution. So think kubernetes, cluster networking type of scenarios. Helping a lot of our customers kind of build out their cloud platforms, both enterprise and service provider space as well. They're kind of cloud platform. Sp yeah, it's a really fun job. To be honest, I didn't know exactly what to expect kind of getting into it, and I've been very, very pleasantly surprised. But it's been an interesting transition from say kind of hands- on network engineer going into network architect. My career and then myself kind of dealing with the onset of cloud and taking on and learning cloud networking when I was working in the enterprise space to then eventually migrating over to Juniper.

Phil Gervasi: Are a lot of the folks that you're working with, maybe your customers, maybe people out in the community at large, would you say that they're cloud engineers, network engineers, maybe former network engineers that are now cloud engineers? What's that makeup of the folks that you interact with?

Shean Leigon: Yeah, it's a great question. It's a little bit of all of that. It's definitely the network engineers that I talk to that are still kind of have that network engineering title. The ones that do, it's a little bit different, right? They're definitely more focused on cloud networking and kind of those aspects to it. And then there's, I'd say that's the majority of the role. And there's some organizations, some of the people that we talk to, their title might be more of a cloud platform type of role, but they definitely lean more towards the networking side. I mean, just from the peer nature of the folks that I interact with.

Phil Gervasi: Yeah. I mean, especially if you think about the nature of the network today. I know at Kentik we have a lot of history on the service provider side, right? But if we are talking about enterprise networking and then enterprise cloud networking, we are talking about a, I almost said hodgepodge, that has a negative connotation. I'm going to say a healthy amalgamation of a variety of different networks. And there is a different aspect of networking in each one of those niches of networking. So I'm configuring my ASRs and ISRs, excuse me, you're both Juniper.

Shean Leigon: It's okay.

Phil Gervasi: My mistake using Cisco load. You're configuring your on- prem routers at the command line, then you're configuring your networking in the cloud and then you're trying to gather metrics from your container networking resources and you have all these components that all feel like networking, but my goodness are they're very different than networking was 10 years ago. The language is changing, what I need to know is changing. I mean, are you seeing that there is kind of an evolving skillset for the network engineer these days?

Shean Leigon: Yeah, absolutely. And I kind of like the way that you articulated that. There's all these different aspects to it. I kind of came from a little bit more of especially starting off, right? Was that traditional networking background, right? Go grab a switch, grab a router, there's a lot of implementation work, a lot of rack and stack cabling, jump in the CLI, get things configured up, upgrade the OS and that that's still there. It still exists. There's still people that go and do that. There's a lot of different tools today to try and make that work better at scale and so forth. But when you take that a little bit of a step further and especially today, it's kind of that's not really enough to solve the needs of networking within a given, especially in the enterprise space within a given enterprise environment. So now you get into Linux networking in some areas, right? And one of the things that it sounds so obvious and rudimentary, but I think sometimes the network engineers, it's easy to forget. It's like the network doesn't start at the switch port, right? The network starts at the host, right? The packets using the TCPIP stack of the host and getting put on a wire on a nick, on a server, and that's where the packet is generated. And then it comes to your switch. And so it's like, " Yeah, sure, of course that's obvious." But if you really kind of think about what does that mean when you look at a given enterprise, if you're responsible for the network, if you're responsible for packet delivery from point A to point C type of thing. And that was how I viewed my role. I was a senior network architect for a pretty large enterprise. We had somewhere around 9, 000 to 9,500 switches and routers in our environment. And when you start thinking about that and you really think about the data center, I think it's important to keep that in mind and really kind of view the network from that standpoint. It starts at the host, so it's really important to think about it from that perspective. And that also changes the viewpoint of things. You start getting into stuff like, how do applications behave and from a networking perspective and kind of what does that look like? And I think it changes the perspective a little bit, especially in the enterprise space. When you think about kind of networking and what that role looks like.

Phil Gervasi: I would say a lot bit, right?

Shean Leigon: Yeah, I mean, it is.

Phil Gervasi: No, no, but seriously, think about it. I mean, just as I was leaving being a, I guess a traditional field or implementation engineer, that was just a few years ago. It wasn't that long ago. And it really felt like, and I worked mostly for VAR so I didn't necessarily always manage my own network. But I worked with some projects that went many months or years because of the implementation schedule. So I almost kind of owned that network. And what I felt like was that there was a shift from managing my boxes to having this loose collection of administrative domains. So I'm managing an SD WAN, so there's a controller but I don't touch the controller because it's not here, it's in the cloud. Okay. And then I'm managing my traffic over the network, but I'm really just managing some decisions I'm making in the overlay. I don't really manage the underlay. So I have these administrative domains where I sort of light touch, manage certain things. Yes, there's a campus where I can literally kick a switch or a UPS in Iraq, but not all of it. And then when you start to add in things like the cloud technologies or if you maybe in some enterprises where they're offloading the management of their data center to an MSP or something like that, I found that you have these collections of administrative domains and then the shift in traffic in general instead of... I mean, do you remember configuring different types of IPSec VPNs in a full mesh over the public internet to connect my branch offices? Who does that? I'm sure some people do that. I'm going to get an email now. But I stopped doing that years ago because it's like everything was going up and out, very little branch to branch connectivity. Maybe it had a print server and maybe a local something, local DNS server not even that. But whatever, other than those very, very niche local applications that you needed to run for some specific purpose, everything was going up and out. Maybe back to the data center if you were back hauling or more and more up and out to the cloud. And we were even offloading to CASB so I didn't own my firewalls anymore. I was basically logging into a portal and managing a collection of firewalls. No, even more than that. Managing a policy, one policy that was pushed to a bunch of firewalls. So that's kind of how I felt, the changing nature of the enterprise network engineer, managing administrative domains, these kind of autonomous networks that all went out. But they were all under my realm of control, my puppet strings, if you will. And so you mentioned how applications communicate though, is that an important thing for... Because that's not something I thought about when I was turning a wrench. How do applications communicate? It's like, " Oh, you got your ping replies, I'm out, I'm done. I'm logging off the WebEx." That's not the case anymore. You're saying engineers, network engineers in particular need to understand how applications communicate?

Shean Leigon: I think it's helpful to a degree. What I found in my experience is when you look at the enterprise space, if I run around talking to other people within IT about the network, they're kind of like, " Okay." They're like, " That's cool." I talk to them about network protocols. They're like, " All right." You're talking to me about BGP and OSPF. Go talk to somebody that's outside of the networking space in your organization about your LSA database, right? And LSAs and you're talking Greek and quite frankly, it's not very valuable to talk to them about that. But where there is value is to talk about people can coalesce around the applications and the things that are necessary to provide the critical services back to your organization, whatever those may be. And so I know for myself, it was when I started getting more involved with our application load balancers ended up falling kind of on the network team. Where we're doing this large migration, you started doing more layer seven type of load balancing, and now you get into, what is TCP doing? How does that actually work? What does a well- behaved application look like and what does one that... I used to joke at times, it felt like we'd get some startup that hired a freshman in college to go write an application for them and sell it to us super cheap, and we were all over it because the price was great. Then we wondered why I was having all these problems and everybody blamed the network type of thing. Once I could speak to other people within my organization at that level, I found one it really elevated my credibility within the organization. So that was really helpful. And I mean, I even got to the point where I would have the server and infrastructure teams and the application teams coming to me and they're like, " Hey, we don't actually think this is a network problem, but can you look at this packet capture because we're not really sure exactly what's happening here. It's not working right and maybe you can help diagnosis and tell us what's happening."

Phil Gervasi: Shean, I don't believe you at all. No server, CIS admin, DevOps person has ever, ever on the face of this earth, ever started a conversation with, " I don't think it's the network, but can you help me?" That's crazy. But I do understand what you're saying. It's like a cultural change, isn't it? Because there's this understanding that the network exists as the substrate, the mechanism to deliver the services, which are usually in the form of an application down to human beings. And since it's this weird collection of all these different types of networks and all these things going on, you have no choice but to have a bigger focus today as a network engineer more than ever on what the application is doing. I was on mute when you said this so you didn't hear me laugh. But you said the words like well- written application. Is that, I think that's what you said, right? What is that? I don't know, but that is another thing. It's going both directions. Yeah, it's network engineers understanding application activity and how APIs calls work and all that. All right, that's cool. But I am talking to DevOps folks that are developers first, but are now learning more and more networking so that way the application there actually perform the way they need to perform. Sometimes because it's in a new cloud native environment or it's in a mixture of cloud native and something that was lifted and shifted, that sort of thing. So I am seeing that kind of cross the aisle communication going on.

Shean Leigon: No, absolutely. I mean, I see that, especially in my role now, a little bit of the nature, the role that I'm in now, I see that a bit as well so there is some definitely more of that cross collaboration. And I think that's where you start getting into some of the elements that you're really providing a high level of value when you can get to that kind of point. It really provides a higher level of value back to whoever your customer is, whether that's internal or external, right? You're able to just really solve some kind of interesting problems at that point. And again, you're looking at it from what I would say of more about what's important to the overall business directive and kind of organization itself rather than just, " Hey, I have two switches plugged into each other. do I see Mac addresses? Okay, we're done," type of thing. Or can I ping? Right? " Hey, I can ping. It must not be the network." Yeah.

Phil Gervasi: Yeah, exactly. I've been there where the pings go through. It's not the network and I'm out, but the reality is like folks say latency is the new outage. There are so many different components that can cause latency and therefore poor application performance and the pings are going through just fine. They're not having a problem, but the latency could be caused some kind of a network latency. And so tracking that down is a little different than what would've done 10 or 12 or 15 years ago. If the things go through like you said, then that's it, we're done. Now we're looking at identifying causes of latency in the path when the path is all over the place. " Do I have DPI going on where it shouldn't be? Do I have latency going in a particular ASN on my providers networks and I have to track it down so I can make a phone call? See, I can't even fix it, but maybe I can track it down with a good visibility tool." So you're really talking about this evolving skillset focused on the knowledge of applications. But can we get specific for a minute? What do network engineers really need to know about application networking? What does that even mean?

Shean Leigon: Yeah, I mean, it's definitely a good question. My perspective on it, and you definitely don't need to... You can feel overwhelming at times, but it doesn't necessarily need to be. And what I really mean by that is, you don't need to understand every component about exactly how the application works that's not what I mean, when I say understanding how the application kind of communicates. It's really about understanding things that maybe at a TCP or an HTTPs type of level, depending on what's going on. You mentioned earlier like CASB and so forth. When you get to that kind of point of things, we're doing more and more now in the middle of the application flow to drive some sort of intelligence into that and make a decision about sending things down a certain path. And sometimes that happens above layer three and layer four. And so it's good to kind of have some knowledge around what that looks like. One of the things that I like to advise people. The old kind of like, some people use this in interviews as well. But the test around, okay, you open up a web browser and you go to a website type of thing, what happens? You type in google. com, what's happening from your computer? Having that type of level of understanding of just the mechanisms that that's going through, what's happening from a DNS perspective, what's then turning around and happening from TLS certificate perspective and then looking at, " Okay, you're doing the HTTP get and how does that come back?" Understanding that type of flow, if you understand that to me you have such a solid foundation in the fundamentals about how things are getting delivered across a network. You couple that with some routing and switching and core network engineering skills, it's a really powerful combination. And I see that as being well suited for network engineers today, especially in the cloud era. The thing you kind of mentioned earlier, that just rings true. And a lot of the times we don't, as network engineers we don't own all of the networks that we're dependent upon anymore. And I think that's the takeaway in my mind from some of the stuff that you were saying earlier that really resonates with me about, " Okay, you have this network over here, you don't have... Is there maybe one ASN?" If you're lucky, there's somebody you can call. Right? That one ASN might be... I mean, you might not have anybody to call whatsoever on that. And so, if you get into those specifics in my mind, if you start understanding again at an HTTPs level, at a DNS level, this kind of what's the end to end delivery? What does that look like? And now you apply that to these different types of infrastructure environments, right? You apply that to your private cloud, maybe there's some public cloud, maybe there's multiple public clouds. It requires a different level of skillset because you're not going to get the CLI inside AWS for you to go look at the router. Right? You're not going to get the CLI level access into their router. You're going to get an abstraction of what does that look like into the public cloud. And so it's kind of like the tools of behavior that maybe you would expect from configuring your routers and switches on premises aren't always there.

Phil Gervasi: Yeah, yeah, that makes sense. The idea here is... You know what it reminds me of? I'm going to show my true colors now. My true nerd colors. There was an episode of Star Trek, The Next Generation, here we go. And I don't remember the episode but the dad who was just like a walk- on roll is walking with his son down the corner of the enterprise. And the son, little boy was saying, and he was 10 years old, nine or 10. He goes, " Dad, I don't want to go to math. I don't want to go to school. I don't want to go to class." And the dad says, " What are you saying, son?" Whatever his name was. " Every 10 year old needs to know calculus." And I remember that because I thought to myself, " Oh, so in this fictional future, knowledge keeps growing and developing and building, and the baseline goes down and down. As far as age or what the minimum requirement is. So I remember for example, when BGP was like, I went through the Cisco path, right, Shean?

Shean Leigon: I started, I did CCMP so I mean, I... Yeah, yeah.

Phil Gervasi: Yeah, exactly. So I use that as my reference just as part of the conversation here, so folks kind of know what I'm talking about. But learning BGP was something like CCIE level, and then it was CCMP level. Well, that's part of the CCNA level now, learning how BGP adjacency forms and how it operates. And so that's how I feel like networking is. Yes, you still have that foundation like you mentioned about knowing how packets move and some basic routing, things like that. That's all still foundational. And you do have folks that are literally physically installing boxes and have to upgrade the OS. So there is still that component as well, knowing the difference between this kind of fiber and that kind of fiber. But the baseline is lower, isn't it? Now an entry level network engineer has to have an incredible amount of knowledge compared to an entry level network engineer 10 or 15 years ago, simply not because we're trying to be mean as an industry, but just because of the nature of networking today. In other words, the nature of application delivery today. It's not me sitting at my machine and an IDF down the hall and a server down the next door.

Shean Leigon: Yeah, absolutely. And I think too, it's also not, people aren't going to their computer to perform specific tasks to go do one thing out of their day. And I think that's driving it, is that everything's connected. Everything. From IOT sensors in places to, it might be in a restaurant checking the temperature of a food or something along those lines to, I'm hearing Las Vegas, all the casino parking garages have those sensors when you drive into them, right? It'll turn from the green to red, and then it'll go tell you how many spaces are available somewhere, right? That's going across an ethernet network. And so everything. The license plate reader for that. Everything is connected and traversing a network today. And so I think that degree of proliferation of technology, and then you also look at the importance, the impact in our lives when there's outages is significantly more. It's yes, that barrier has gotten lower. I also think the criticality and dependence on good networks is stronger than at least I've seen it in my 20 years of being in technology.

Phil Gervasi: Oh, yeah, right. I mean, yeah, mundane stuff for sure and things that we use for entertainment. But I mean, I can think of large healthcare systems that are hybrid and have sensor networks that are... I mean, we're talking about healthcare, we're talking about hospitals and operating rooms. There's no more mission critical than that, I don't think. And we're talking about military and you two gentlemen, both having experience in the United States military is built on a lot of this technology. And that's, again, all mission critical. So without the network being able to pass these services again, which I always see in the form of applications, for the most part. We have nothing. We're done. We're going back to terrestrial radio, which I guess we could do. I've seen enough post apocalyptic movies that are very interesting. And to be honest, some of it's appealing to me. I love going up to the mountains with my family and unplugging on purpose, so I get that. But the reality is, yeah-

Doug: Phil, you're taking notes, you're watching these and fill in a notepad. Yeah, it's an instructional video.

Phil Gervasi: I'm taking notes. Yes, absolutely. It's like, Okay, buy a hundred acres here, build bunker here." But in any case, the spirit of what I was trying to say is that we are at a point in our society, we have an incredible dependence. It's not just the mundane, but it is those mission critical things like you said. Some of the sensor networks that you mentioned are absolutely mission critical. So then as just another aside, you mentioned quickly in passing in HTTP GET. I didn't know what that was until five years ago. And I've been in networking for a long time, and that's because I didn't need to know. But then all of a sudden I'm helping to troubleshoot those things and looking at, all right, we have a literal delay in this GET request, and it's related to DNS. There's an actual file that's holding this up because this DNS server is not responding in enough time and so that file's not transferring in enough time, and it's one part of an entire webpage of files for the user experience. So, there I was troubleshooting that kind of transactional stuff. So then what skills specifically that you personally would you personally identify as the new skills that somebody getting into this field, and specifically networking, however we want to define that, should be learning? Should they be going down a certification path and doing that? Should they be focused on building their developer skills? All of it? What do you think?

Shean Leigon: Yeah, I mean, I'm still a big proponent of the fundamentals. I don't think you can get away with it. You can get away from that. So if certifications are a good forcing mechanism for somebody, or to get exposure to maybe technologies that they don't interact with in their day- to- day job, that type of thing, I think a great tool for that. So yes, call it your core switching and routing type of fundamentals. How is routing done? How are packets delivered? Once you just think about how does a given router work of a destination look up and doing longest prefix match, and there's different tables that get turn around and utilized of your rib and your fib, and what does that look like. Then start getting into the protocol development. I'm a big fan of BGP, of course. Like I said, I work at Juniper. We love BGP for everything, but not... Big fan of BGP. So you get into BGP, you get into OSPF. Is EVPN a core fundamental requirement these days everywhere? I think that's probably disputed. You don't have to start with your VPN by any means. But once you start kind of understanding the foundations of some of these protocols, what they have in common, kind of how they work, of course it's always easier when you can apply it to your environment. Say once you have a good foundation of that, now you can start driving into, of course there's some skill sets there from an automation perspective. If you have the ability to write a little bit of Python, it's going to make your life a lot easier. Much, much easier. And I think that's a good skillset, especially for people up and coming. I struggled with that for the longest time because I came from a little bit of a different background. I could solder resistor onto a circuit board once upon a time. Don't have me do that today, it'll be pretty ugly. But once upon a time I could do that. Right? And those skills aren't needed anymore but things around some basic development, some automation, being able to do some basic type of coding skillsets. Absolutely. Now I take that a step further, and if you understand those networking concepts about what those look like, and now you kind of take that into the cloud era. More and more you start, I spend a lot of my day around Kubernetes networking and what does that look like. Cloud platforms these days are largely built upon Kubernetes environments of some way, shape, or form. So if you're somebody that's building out like a private cloud environment in your organization, that's typically what I see is typically people building that on Kubernetes, OpenShift, some sort of Kubernetes distribution. So understanding networking in that type of space, let's say it's a little bit more advanced. But that's kind of when you start getting into the cloud, understanding Linux networking anyways. And getting into that space and it's kind of understanding what's happening there. I've found, and I'm probably a bit biased on it. I've found that people that can match those two skillsets together, it becomes pretty powerful.

Doug: Can I ask a question, Shean? So how about a slight tangent from that question is, so what were some skills that you, maybe it's not a technical skill or hard skill, but what were some lessons from your military service that you still use, that still serves you well? Are there any?

Shean Leigon: Oh, there's tons.

Doug: Okay. I figured there would be. I thought-

Shean Leigon: Yeah, I mean. Of course, it's a great question. I mean, there's tons. I would say there's a level there that of probably some of the more kind of baseline things around just being able to really work to something to get the accomplishment on the other side. Sometimes I think that can be difficult, especially these days in a given work environment. It's really easy to go start a bunch of things, but having the skillset to kind of know when to say no, and also to just drive through and kind of prioritize things, I think is extremely, extremely helpful. Prioritizing your work, being able to do those types of things I think is helpful.

Doug: What's an example of the learn to say no?

Shean Leigon: Oh, there's a...

Doug: You're trying to not overstretch yourself. That's what you were saying, right?

Shean Leigon: Yeah. Try not to overstretch yourself and also understanding where you can provide the most value is going to be the most valuable thing back to your organization. Sometimes people will come and ask for help simply because they have a relationship, they don't know where to go, and that's a good thing. You shouldn't shy away from that. Lean into it, but also be willing to say, " Hey, let me go pull in the right person to kind of help with that. And then I have this other work I need to focus on to get done, because that's kind of the more urgent matter." There's an element of that I think that I picked up from the military, oddly enough, of being able to really specify and kind of hone in on it. So I mean, that's probably a simple one.

Doug: Funny, I have a similar lesson as well in the... And maybe you found this as well, but as a junior officer, you end up your social group on the base especially when you're overseas, the Americans need to hang out together and you start to meet all the other junior officers. And so each person is, there's only a couple junior officers in each squadron. So on the base there's like your social group covers every main function of the base. And so you end up, the people you're going out to the bar with are the people who basically, they're the junior guys so they don't have a lot of experience. They're really not, they're not that great at stuff. They do have authority, even though it may be misplaced. So if they really felt inspired, they could order somebody to do so. But I had a couple times where I realized how powerful that was. I got to Aviano in August, 2001. The following month was September 11th. We were in a mobile unit, so the rest of the time we were just constantly getting our chain yanked of getting deployed. Ultimately, Shean and I ended up deploying to Iraq in November, 2003, but that earlier that year, there was at least three, maybe four times we were told to start packing up and we're on our way out the door. Then they're like, " Oh, nevermind." And then we're like, " All right, fine." I guess, this is very, very nerve- wracking. But I know that it was one of these times I think when, I can't remember at what point it was but we had stuff we had to get out. This is just during the, when Afghanistan was, Iraq had not started yet. We had power generation guys that we needed to get into Pakistan. And so there was something, like a task came down. We had to get somebody out in 12 hours. Tell a kid, pack your stuff, get this gear, you're getting on a plane and there's no time, and the plane's landing and you're getting on it. And there's some sort of snag in the logistics where somebody was not... They wouldn't let him ghost. So he was getting his shots and doing all these things, and they would let the paperwork go and take your place as you're getting on the plane until you finally arrive. And they wouldn't let him this. I knew the officer, he was a friend of mine, and I just called him, I was explaining the situation. I was like, " Can you make this happen?" He's like, " You got it." And I turned around, I was like, " Oh, this is really powerful, just to know other people and just know if I could just pick up a phone... And it was a common sense thing. Everything worked out. It was the way it was supposed to work. I just needed the right person to talk to, explain the situation. And I was like, " I need to make a point of this. This is just networking in general." But I kind of, ever since then I was like, " Oh, if you can kind of maintain some good rapport with people, a lot of people like to help." And if it's easy, they're happy to hook you up with something if it doesn't cost them a lot. So that was one lesson, it's a little bit relates to what you're describing, I think.

Shean Leigon: Yeah, no, I think that that's really true. That's definitely one. There's so many other things, like from military time of sometimes you just have to get the work done, right? You just got to figure it out, and you just got to press through and dealing with non- optimal situations to get to the outcome that's required, I think is probably another one of those skill sets that I use all the time. It's easy, and without getting too philosophical. But it's easy to kind of walk into a job or walk into an organization and critique. But if you walk in with a little bit of... If you approach the situation with more, they say approach things with curiosity rather than judgment. If you approach it more with curiosity and it's like, " Hey, how can I help and kind of look at things from a different little bit of a different perspective offer to help less judgment. And you kind of assume that, hey, you give people the benefit of doubt that they're all trying to do their best to get to a good outcome of what you need to get to. And I think that for me anyway, it served me well to go far in my career and it's really helped me out. And other people have been willing to open up opportunities for me later on down the road that I wouldn't otherwise have without that being kind of happening. I know we kind of went off on a lot of this side discussion, but I think it's a good point especially as people are kind of thinking about their careers, some maybe the non- technical aspects of it as well.

Phil Gervasi: Yeah, the non- technical aspects of my career are some of the things that have driven my career in the most recent days. And I have to admit, I don't have a military background by any means, but I didn't start my professional career in technology. Well, let me rephrase that. I didn't start my professional life in working in technology. I was in education, and I always kind of dumped on that for a long time. Because it's like, " I wish I got a CS degree and I wish I got into tech earlier," things like that. But the last five years, seven years of my career have been driven predominantly by the skills that I developed as a classroom teacher. And so here I am providing for my family, I have a wife and children and I pay mortgage, so it's not like it's just a fulfillment of my desires. No, it's like a very practical thing, growing a career. So, though my experience is very different of course, it does what you say, it does resonate as far as the non- technical skills, the people skills. I don't want to say social skills, but the ability to go beyond just seeing packets and CLI and configurations, things like that. Definitely a tangent, but a very good tangent in the sense that it's part of your journey, part of who you are, and that's why we wanted to have you on today. In fact, I think it would be awesome to just focus on that for a show in the future and just focus on how this, having a background in armed forces, whether it's in the United States or not, depending on the guest, has helped shape your career in technology. It can be very interesting. But for now, this has been great, Shean. Great, Doug, thank you for joining. I really appreciate it. If folks have a question for you, Shean, how can they reach out to you online?

Shean Leigon: Yeah, I'd say probably the best way is on Twitter. It's S- H- E- A- N- L- V. So Shean LV on Twitter is probably the best way to reach out to me. And yeah, I really appreciate you both having me on, and this is a really good conversation.

Phil Gervasi: Yep, agree. Doug, how about you? How can folks reach out to you online?

Doug: Yeah, I'm on Twitter and LinkedIn. Just my name, nothing clever. I'm not that clever. And then Shean I'll say for, so it's L- E- I- G- O- N. There is a legion of misspellings out there, I'll say. Leigon. Be careful where the eye is in that name because it may jump out of your view. But anyway, yes, so it is great talking to you, Shean, and as always, and let's keep in touch.

Phil Gervasi: Doug, you just said you weren't clever and here you are coming up with all these clever fun, yeah.

Doug: Yeah. Look at me, man. I'm selling myself short.

Phil Gervasi: Absolutely. And you can find me on Twitter still. I am active there. Network_Phil. You could search my name on LinkedIn. Now, if you are interested in being a guest on Telemetry Now, or if you have an idea of a episode idea for a podcast, we'd love to hear from you. Email us at telemetrynow @ kentik. com. So until next time, thanks for listening. Bye- bye.