The journey from network to cloud engineer - a career evolution

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 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 and 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, and that's what we'll be discussing today. So with me is Sean Legan 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 Philip Jervasi, and this is telemetry now.

Hey, Sean.

It is really great to have you. Thanks for joining today. Much appreciated. I 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 and Doug, Always great to have you joining us, our resident director of internet analysis, extraordinaire. I'm gonna add that on as well.

Just getting to know you more over the past year and a half working Kentech. You know, I'm gonna I'm gonna say extraordinaire is not even sufficient. But in any case, going back to you, Sean, can you give us a little bit of background of where you started in technology, and then maybe what you're doing these days.

Sure. Yeah.

I I kinda had a cheat code of of starting through the Air Force So, I didn't know that much about computers.

Ended up wanting to to kind of join the military, to go do something different in life, and found a job description that sounded cool. So, anyway, it went after that. I was in the air force for about six years and then ended up, you know, 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, yeah, kinda made my way from there over to to large enterprise.

More in kind of the the standard private sector.

Large enterprise.

Today, I'm, you know, today I'm at Juniper Networks, so I do product management within Juniper Networks and kind of our cloud and data center team.

Okay. Great. And then, Doug, I know that you and and Sean know each other from your time serving together in the US Air Force. Correct?

Yeah. So this is kinda one of those weird things of, reconnecting with someone that you knew, like, many lifetimes ago it would it feels, so Sean mentioned being in the air force and, I think his first assignment was in Aviano Airbase in Italy. And so I was his flight commander. I was a commanding officer. Now we're contemporaries in the industry, but, in those days, you know, I was maybe twenty four. He's nineteen or something. I was, you know, I was, I got to be a, his his boss's boss, whatever.

But yeah, Sean was working on, tactical telephone switches. I remember, like, so, like, thirty eight sixty fives for people in the military, knowing all this old green equipment that fits into transit cases. You throw on the back of a truck. And, yeah, I remember, remember Sean. And, it was really neat to, come across his name later on.

I don't know. I don't know. Maybe the last ten years, I think we we kinda 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, 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. So it's it's great to re, get to know you, Sean.

Yeah. Thanks.

Likewise. It's it's definitely been fun, you know, from, boy, couple of mannogs ago. Right? We had the Tuney in San Francisco to kinda meet up and go grab dinner and catch up and so forth. So, yeah, multiple times since then. So, yeah, it's been great.

So, Sean, what do you project or rather, yeah, product manager for specifically at Juniper? What's the what's the line?

Yeah. Could question. So I work, predominantly in in our c and it's called c and two. It's basically cloud native, networking solution. So think, you know, Kubernetes cluster networking type of scenarios, helping a lot of our customers kind of build out their cloud platforms, you know, both enterprise and service provider space, as well, and, you know, they're kinda, cloud platforms. So, yeah, it's It's, it's a really fun job that I, to be honest, I didn't know exactly what to expect kinda getting into it. And, very, very pleasantly surprised, but it's been an interesting transition from, say, you know, kind of hands on the ARC Engineer going into network architects.

My career than myself kind of dealing with, you know, the the onset of cloud and and taking on and learning cloud networking, when I was working in enterprise space to to then, yeah, eventually migrating over to to Juniper.

Do or 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 narrow cloud engineers? What's the what's that makeup of the folks that you interact with? Yeah.

It's a great question. You know, it's it's it's a little bit of all that. It's definitely the network engineers that I talk to that are still kinda have that arc engineering title, the ones that do, you know, it's a little bit different. Right?

They're, they're definitely more focused on cloud networking, kind of the those aspects to it. And then there's, I'd say that's the majority of the role. You know, there's some organizations, some of the people that we talk to know, their title might be more of like a, like a cloud platform type of, type of role, but they definitely, you know, lean more towards the networking side. I mean, just from the the pure nature of the folks that that I interact with?

Yeah. I mean, especially if you think about the nature of the network today. Right? So I know, you know, At Kentech, we're we have a lot of history on the service provider CIDR.

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 gonna say a healthy amalgamation of a variety of different networks, and, and, 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, your phone number. My mistake. Using Cisco, you're configuring your on prem routers at the command line and you're configuring your, you know, your, your, you're 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 ten years ago.

So I'm suit, you know, the the language is changing. The what I need to know is changing. I mean, are you seeing that that there is kind of an evolving skill set for the network engineer these days? Yeah.

Absolutely. And I kinda like the way that you you articulated that you know, there there's all these different aspects to it.

You know, if we think, like, you know, I kinda came from a little bit more especially starting off, right, was that traditional networking background, right, go grab a switch, you know, grab a router, You know, there's a lot of implementation work, a lot of rack and stack cabling, jumping the CLI, get things configured, upgrade the OS.

You know, and that it that that's still there. Right? It still exists. There's still people that go and do that. There's a lot of different tools today to to try and make that work better at scale and so forth. But, you know, when you, you take that, like, a little bit of a step further, and, especially today, it's kinda you know, that's not really enough, right, to to solve the needs of networking within a given, especially the enterprise space.

Know, within a given enterprise environment. So now you get into, like, Linux networking, you know, in some areas, right, in in One of the things that, you know, it sounds so, like obvious and rudimentary, but I think sometimes in network engineers, it's easy to forget. It's like, and the network doesn't start at the switch port. Right? The network starts at the host.

Right? The package 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, you know, it's like, yeah, sure. That that that, of course, that's obvious. But if you really kind of think about what does that mean when you look at, in a given enterprise?

If you're responsible for the network, if you're responsible for packet delivery from, you know, point a to point c type of thing.

And that that was how I viewed my my role. I was assuming network architect for a pretty large enterprise.

You know, we had somewhere around, like, nine thousand to ninety five hundred switches and routers in our environment.

And, you know, when you start thinking about that, you really think about the data center. I think it's important to keep that in mind.

You know, it really kind of view the network from that standpoint. Right? It it's it starts with the host. So it's really important to to think about it from that perspective. And that also changes, you know, the viewpoint of things, right? You start getting into stuff like, you know, how do, how do applications behave in, in, you know, from a networking perspective, and you know, kind of what does that look like? And, you know, I think it changes the perspective a little bit, especially in the enterprise space when you think about kind of networking and and what that role looks like.

I would say a lot then.

Right? Yeah.

I mean, it is. Seriously, think about it. I I I mean, just as I was leaving being, I guess, a traditional field or implementation engineer, that was just a a few years ago. It wasn't that long and it really felt like and I I worked mostly for VARs, so, I didn't necessarily always manage my own network.

But, you know, I worked with some projects that went many months or years, because of the implementation schedule. So I almost kinda own that network. And, what I felt like was that there was a shift from, like, managing my boxes to having this, like, loose collection of administrative domains. So I'm managing, like, an SD WAN, so there's a controller, but I don't touch the or 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. Don't really manage the underlay. So I have these these administrative domains where I sort of light touch, manage certain things. Yes, there's a campus where I can, like, literally kick switch or a UPS in Iraq, but not but not all of it. And then when you start to add in things like the cloud technologies or, if you're if you maybe, you know, in 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 of administrative domains, and then the shift in traffic in general instead of, I mean, do you do you remember, like, configuring, like, different types of IPsec VPNs and a full mesh over the public internet to connect my branch offices. Who who does that? I'm sure some people do that. I'm gonna get a email now.

But I I stopped doing that years ago because it's like everything was going up and out. Very little branch to branch connectivity. Maybe you had like a print server and a maybe a local something, you know, local DNS server, not even that. But whatever, other than those very, very niche, like local, applications that you need to run for some specific purpose, everything was going up and out.

Maybe back to the data center, if you were backhauling or more and more up and out to the cloud.

And we're even offloading to Casby. So I didn't own my firewalls anymore. I was 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 kinda how I felt the changing nature of the enterprise network engineer, managing administrative domains, these kind of autonomous networks, it all went out, but they were all under my realm of control, my 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. You know, 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.

I think it's helpful to a degree. You know, what I what I found in my experience is when you look at like the enterprise space, if I run around talking to other people within IT about the network, you know, they're kinda like, okay. Like, that that's cool. I talked to them about network protocols.

They're like, alright, you know, you're talking to me about BGP and OSPF and, you know, go go talk to somebody that's outside of the networking space in your in your you know, organization about your your LSA database. Right? In in LSA's. And you're you're talking Greek and quite frankly, it's not very valuable to talk to about that.

Right? But but where there is values to talk about, you know, people can kinda coalesce around the applications and the things that are necessary to provide you know, the critical services back to your organization, whatever those may be. And so, you know, I know for myself, it was It was when I started getting more involved with, you know, our application load balancers ended up falling kind of on the network team. We were doing large migration, and you start doing more layer seven type of load balancing, and now you get into, you know, what is TCP doing?

Right? Like, how does that actually does that actually work? What does a well behaved application look like? And what does one that, you know, I used to joke right at times, it's it felt like You know, we'd get some startup that hired, you know, a freshman in college to go write an application for them and and sell it to us super cheap.

Right? And we were all over it because the price was great. And then we wondered why, you know, is having all these problems and everybody blame the network type of thing.

Once I could Yeah.

Once I could speak to other people within my organization at kind of that that level, I I found one, like, it really elevated my credibility within the organization.

You know, so so that was really helpful. And, you know, I mean, I even got to the point where, like, I would have the, the, the server and infrastructure teams and, you know, the application teams coming to me, and they're like, Hey, we don't 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. You know, it's not working right, and maybe you can you can help diagnose and tell us what's happening.

Sean, I don't I don't believe you at all.

No no server sys 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 that's crazy. But I do understand what you're saying. It's like a cultural change, isn't it? Because there is this understanding that the network exists as the, 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, you know, weird collection of all these different types of networks and and all these things going on, you have no choice, but to have a bigger focus today as a network and 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 thing?

I think that's what you said. Right? What is that? I don't know. But that is that is another thing.

It's it's going both directions. Yeah. It's network engineers understanding, application activity and how API's calls work and all that. Alright.

That's cool. But I am I am talking to DevOps folks that are developers first, but are now learning more and more networking. So that way, the applications they're right, actually, perform the way they need to perform. Sometimes because it's like in a new cloud native environment, or, you know, 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.

No. Absolutely. I mean, I see that, especially my role now, right, a little bit of the nature, the the role that I'm in now. I see that a bit well as that, you know, it is, there is some definitely more that cross collaboration. And in You know, I think that's where you start getting into some of the elements that you're really providing like a high level of value.

You know, when you can get to that kind of point. Like, it it it really provides a higher level of value back to, you know, whoever your customer is, whether that's internal or external. Right?

You're able to just really, you know, solve some kind of interesting problems at that point. And and again, you're looking at it from you know, what I would say of of more about what's important to, you know, the overall business directive and and kinda, you know, organization itself rather than than just, you know, hey, I have two switches plugged into each other. Do I see MAC addresses? Okay. We're done.

Hypothetically, or can I ping? Right? You know, hey, I can ping it. Must not be the network.

Yeah.

Yeah. Exactly. I've been I've been there where, you know, the pings go through. It's not the networking I'm out, but the reality is, you know, 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. You know, they're not they're not having a problem. But the latency could be cause some kind of a network latency, you know. And so tracking that down is is is a little different than than what I would have done ten or twelve or fifteen years ago, when 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. You know, do I have DPI going on where it shouldn't be? You know, do I have, latency going in a particular ASN on my provider's networks? And I have to track it down so I can make a phone call.

See, I can't even fix maybe I can track it down with a good visibility tool. So, you know, you you're really talking about this evolving skill set focused on on, the the knowledge of applications, but can we get specific for a minute? What do network engineers really need to know about application networking? Like, what does that even mean?

Yeah. I mean, you know, it's it's definitely a good question. What I my perspective on it, you know, and you definitely don't need to, like, It it can feel overwhelming at times, but it doesn't necessarily need to be. What I really mean by that is, you know, You don't need to understand every component about exactly how the application works.

That's that's not what I mean. When I say understanding how the application kinda communicates, really about understanding things that maybe, you know, a a TCP or an https, you know, type of level depending on what's going on. You mentioned earlier like Kasby and and so forth. You know, 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, you know, above layer three and layer four. And so it's good to kinda have some knowledge around what that looks like. One of the things that I like to, to, you know, advise people that the old kinda like, some people use this in interviews as well. Alright?

But the the test run, like, okay, you know, you open up a web browser and you go to a website type of thing like what happens. Right? You type in you know, Google dot com, what's happening from your computer. Having that type of level of understanding of just, you know, the mechanisms that that's going through what's happening from a DNS perspective.

What's then turning around and happening from, you know, TLS certificate perspective.

And then looking at, okay, you're doing the get, and how does that come back?

Understanding that type of flow, like, if you understand that to me, like, you have such a solid foundation in the fundamentals about how things are getting delivered across the network.

You couple that with Yeah. You know, some some routing and switching and core network engineering skills. It's like a really powerful combination, and and I see that as being well suited for network engineers today, especially in the, in the cloud era.

You know, the the thing you kinda mentioned earlier, that just, you know, rings true. And a lot of the times, we don't as network engineers, we don't own all over the networks that we're dependent upon anymore.

Right? And I think, like, that's the takeaway in my mind from some of the stuff that you were saying earlier that really resonates with me about, like, you know, okay, you, you have this network over here. You don't have emails or 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.

You know, on that. And and so, yeah, it's if if you get into those specifics in my mind, if you start understanding again, like, at a https level at a DNS level. It's gonna happen. What's the end to end delivery of 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.

You know, it it requires a different level of skill set because you're not gonna get the CLI inside AWS for you to go look the Look at the router. Right? You're not gonna get the CLI level access into their router. You're gonna get an abstraction of what does that look like, you know, in into into the public cloud. And so, you know, it's kinda like the the tools of behavior that maybe you would expect from configuring you know, your your routers and switches on premises aren't always there. Yeah.

Yeah. That makes sense. You know, the idea here is, you know, you know what it reminds me of, I'm gonna 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 the dad who was just like a walk on role is walking with his son down the quarter of the enterprise. And the son, the little boy, was saying that and he was ten years old, nine or ten. He goes, dad, why don't wanna go to math? I don't wanna go to school. I don't wanna go to class. And the dad says, what what are you saying, son, whatever his name was? Every ten year old needs to know calculus.

And and it, you know, I remember that because I thought to myself, oh, so in this fictional future, you know, knowledge keeps growing and developing and building and and The baseline goes down and down, like as far as age or, like, what the minimum requirement is. So I remember, for example, when BGP was, like, I went through the Cisco pad, right, Sean?

I started. I had a six UNP. So, I mean, I Yeah. Yeah.

Yeah. Exactly.

So so I use that as my reference just as part of the conversation here. So folks can know what I'm talking about, but, you know, learning BGP was something like CCI level. And then it was CCMP level. Well, that's part of the CCNA level now, learning how a BGP adjacency forms and, you know, and and how it operates, And so, you know, that's how I feel like networking is.

Yes. You still have that foundation, like you mentioned, about, you know, knowing how packets move and and some basic routing, things like that. That's all 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, you know, the difference between this kind of fiber and that kind of fiber.

But the baseline is lower, isn't it? You know, now, you know, an entry level that engineer has to have an incredible amount of knowledge compared to an entry level network engineer ten or fifteen years ago, simply not because we're trying to be mean as an industry, but just because of the nature of 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 Yeah.

Absolutely. And I think too, you know, it's also not people aren't going to their computer to perform specific tasks to go do one thing out of their day. Right? I mean, and I think that's what's driving it, is that everything's connected.

Everything from, you know, IoT sensors and places to you know, it might be in a restaurant checking the therm, you know, the temperature of a food or something along those lines, right, to, you know, I'm hearing Las Vegas, all the the casino parking garages have those sensors when you drive into the might all turn from, like, green to red. Then I'll go tell you how many spaces are available somewhere. Right? That's going across an ethernet network.

You know, and and so everything, the license plate reader for that. Everything is is connected and traversing a network today. And so I think that, degree of proliferation of, of, you know, technology, and then you also look at the importance. The impact in our lives when there's outages is significantly more. And so, you know, I, I, is it, is yes, that barrier has gotten lower. I also think the criticality independence on, on good networks is stronger than, at least I've seen it in, in my twenty years of being in technology.

Oh, yeah. Right? I mean, yeah, mundane stuff for sure. And, you know, things that we use for entertainment, but, I mean, I can think of large healthcare systems that are hybrid and multi cloud and and, have sensor networks that are I mean, we're talking about healthcare.

We're talking about hospitals, peep, and operating rooms, right? There's no more mission critical than that. I don't I don't think. And and we're talking about, military and the and you two gentlemen both having experience in the United States military, is built on on a lot of this technology.

And that's, again, all mission critical. So, without without the network being able to to pass these services again, which I I always see in the form of applications for the most part. We we have nothing. We 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 and to be honest, some of it's appealing to me. Like, I I have I love going up into the mountains with my family and unplugging on purpose so I get that.

But the reality is, yeah, Phil, Phil, you're you're taking notes You're watching these and fill in a notepad.

Yeah. It's an instructional video.

I'm taking notes. Yes. Absolutely. It's like, okay. Bye. Hundred acres here. Build bunker here.

But, but in any case, you know, my the spirit of what I was trying to say is that, you know, we we are at a point 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, so then so then as just another aside, you mentioned, quickly in passing an HTTP get. I didn't know what that was until like five years ago. And I've been networking for a long time. And that's because I didn't need to know.

But then all of a sudden, I'm I'm helping to troubleshoot those things and looking at, alright, we have a we have a literal delay in this get request and it's related to DNS. There's an actual file, you know, that's that's holding this up because this DNS server is not responding in enough time, and so that that file is not transferring in enough time. And it's one part of an higher webpage of of files, you know, for for the user experience. So there I was troubleshooting that that kind of transactional stuff.

So then what 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 wanna define that, should be learning. Should they be going down the certification path and and doing that? Should they be focused on, building their developer skills, all of it. What, what do you think?

Yeah, I mean, you know, I'm still a big proponent of the fundamental I don't think you can get away with it. You know, you can get away from that. So, you know, if if if certifications are a good, like, 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. Right? I think a great tool for that.

So, yes, call it your, your, you know, core switching and routing type of type of, fundamentals. You know, how is routing done? How are packets delivered?

Once you just think about, like, how does a a given router work of a destination lookup and doing longest prefix match? And, you know, there's different tables that get turn around utilized of your, you know, your, your, your rib and your fib. And what does that look like? And then start getting into the protocol development You know, I'm a big fan of of BGP, of course.

Like I said, I work at Juniper. We love BGP for everything. But, no, you know, Big fan of BGP. So, you know, you get into BGP, you get into OSPF, you know, is is EVPN a core fundamental requirement these days everywhere.

I I think that's probably, you know, disputed. You don't have to start with your VPN by any means. But Once you start kinda understanding, like, the foundations, right, of, of some of these protocols, what they have in common, kinda, how they work of course, it's always easier when you can apply it to your environment. So once you have, like, a good foundation of that, now you can start driving into know, of course, there's some skill sets there from like an automation perspective. If you have the ability to write a little bit of Python, it's gonna make your life a lot easier.

Much, much easier. And I think that's a good skill set, you know, especially for people up and coming, you know, I struggled with that for the longest time because, you know, I came from a little bit of a different background. Right? I could I could solder, you know, resistor onto a circuit board, once upon a time. Don't don't have me do that today. Be pretty ugly.

But, you know, once upon a time, I could do that. Right? And, and, you know, those skills aren't needed anymore. But things around, like, some basic developments, some automation, being able to do some basic type of coding skill sets. Absolutely.

Now take that a step further. And if you understand those networking concepts, about what those look like. And now you can take that into the to the cloud era.

More and more you start, you know, I I spend a lot of my day around Kubernetes networking and kinda what does that look like?

You know, cloud platforms these days are largely built upon you know, Kubernetes environments of some, some way shape or form. So if you're somebody that's building out like a private cloud environment, you know, in your organization, that's typically, you know, what we what would I what I see, is typically people building that on, you know, Kubernetes openshift, some sort of Kubernetes distribution So understanding networking in that type of space, let's say, you know, it's a little bit more advanced.

But that's kind of when you start getting into the cloud understanding Linux, networking, anyways, and 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 kinda match those two skill sets together you know, it becomes it becomes pretty powerful.

Can I ask you a question? Sean, so how about, a slight tangent from that question is, so, what were what were some, skills that you maybe maybe it's not a technical skill or a hard skill, but what was some lessons from your military service that, you still use, that still serves you well. Is there there any? Do you have any?

Oh, there's tons.

Okay. I figured there would be.

I thought Of course, you know, there's it's a great question.

I mean, there's there's tons. You know, I would say, you know, there's a level there that of of probably some of the more some of the more kind of like baseline things around just you know, being able to to really work to something to gonna 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 but having the skill set to to kind of know when to say no, and also to just drive through and and kinda prioritize things I think is extremely, extremely helpful prioritizing your work, being able to do those types of things, I think, is is helpful.

What's an example of, that learned to say no?

You know, there's Just you're trying to not over stretch yourself.

Yeah.

That's what you're saying. Over stretch yourself and also understanding where you can provide the most value is gonna be the most valuable thing back to your organization.

Sometimes people will come and ask for help simply because they they have a relationship. They don't know where to go. That's a that's a good thing. We shouldn't shy away from that.

Lean into it. But but also be willing to say, you know, Hey, let me go pulling the right person to kinda help with that.

You know, and then I have this other this other work I need to focus on to get done because that's kind of the more urgent matter. There there's an element of that. I think that I picked up from the military oddly enough of of, you know, being able to really specify and kind of kind of hone in on it.

Yeah. So I I mean, that's probably like a simple one.

It's fun. It's funny. I have a I have a similar I have a similar, lesson as well, you know, in the maybe maybe you found this as well. But in, as a as a junior officer, you end up your social group, on the base, especially when you're overseas, Americans need to hang out together.

And, you start to meet meet all the other junior officers. And so each person is there's only a couple junior officers in these squadrons. 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 you're going out to the bar with are the people who basically They're the junior guys, so they don't, like, they don't have a lot of experience.

They're really not, you know, they're not that great of stuff. You do have authority even though it may be misplaced.

So if they really felt, you know, inspired they could order somebody to do something, you know, but I had a couple times where I I realized how powerful that was, you know, I got to Aviano in August two thousand one. The following month was September eleventh. We were in a mobile unit so the rest of the time there was just we were just constantly getting our chain yanked of getting to, deploy. Ultimately, Sean and I, and deploying to Iraq in November two thousand and three.

But, you know, that earlier that year, there was, like, at least three, maybe four times. We were told to start packing up, and we're on our way out the door and then I'm like, oh, never mind, you know, and then we're like, alright, fine. You know, I guess this is very, very nerve wracking, but I know that there was one of these times, I think, when, can't remember what point it was, but we had stuff we had to get out. This is just during the, when Afghanistan was the, like, Iraq had not started yet.

And so the, we had, power generation guys that we need to get into Pakistan, and there was something like a task came down. We had to get somebody out, like, in twelve hours, telekid pack your stuff, get this gear, you're getting on a plane, and there's no time. And the, and the plane's landing and you're getting on it. And the, there's some sort of snag in the logistics where somebody was not.

Yeah. They were, they wouldn't let him ghost. So he was getting 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, and they wouldn't let them, let it wouldn't let them do this.

And so I knew the the officer, who's a friend of mine. And I just called and I was like, explain the situation. I was like, can you make this happen? He's like, you got it.

And, 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. Like, every 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 was like, I need to make a point of this. It's just just networking, you know, in general. But I kind of ever since then, I was like, oh, like, You know, if you can kinda maintain some good reporter with people, a lot of people, like to help, and if it's easy, you know, they they're happy to hook you up with something.

If it doesn't, you know, cost them a lot.

So that was one, you know, lesson. It's a little a little bit relates to, you know, what you're describing, I think.

Yeah. No. I I think that that's really true. That that's definitely that's definitely one. You know, there's so many other things, like, from you know, military time of, like, sometimes you just have to get the work done. Right? You just kinda figure it out and, like, you just gotta press through and and, you know, dealing with non optimal situations to get to the outcome that's required, I think, is probably another one of those skill sets that, you know, I use all the time.

It it's it's easy and without getting, like, too philosophical, but You know, it's easy to kinda like walk into a job or walk into a organization and and critique you know, but if you walk in with like a little bit of, you know, if you approach the situation with more, like, you know, they say like approach things with curiosity rather than judgment. Right? If you approach it more with like curiosity, And it's like, Hey, you know, how can I help, you know, and, and kind of look at things from a different little bit of a different perspective, offer to help less judgment, and, you know, you kind of assume that and you give people the benefit of doubt that they're all trying to do their best to to get to a good outcome of what you need to get to? And, you know, I think that for me anyway.

It's served me well to go to go far in my career, and it's really helped me out. And other people have been willing you know, to open up opportunities for me later on down the road that I wouldn't otherwise have, you know, without that being being kinda happening. So I know I know we kinda went off on a lot of this, this side discussion, but I think it's a good point people are kinda, you know, thinking about their careers, some of the, maybe the non technical aspects of it as well.

Yep. 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 I don't have a, a military background by any means. But I, 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 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, you know, providing for my family, I have a wife and children, and we pay them I pay the 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 You know, though my experience is very different, of course.

It does what you say does resonate as far as the, the non technical skills, the people skills, the I don't wanna say social skills, but the ability to, you know, go beyond just seeing packets and, and, clI and configurations, things like that. So definitely, 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 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 and technology. It can be very interesting. But for now, this has been great, Sean. Great Doug. Thank you for joining. Really appreciate it. If folks have a question for you, Sean, how can they reach out to you online?

Yeah. I'd I'd say probably the best way is on on Twitter.

It's s h e a n l v. So Sean l v. On Twitter's probably the best way to, to reach out to me. And, yeah, I really appreciate you both having me on, and, it was a really good conversation.

Yep. Agree. How about you? How can folks reach out to you online?

Yeah. I'm on, Twitter and LinkedIn. Just my name. Nothing nothing clever. I'm not that clever.

But, and then, and then, Sean, I'll I'll say for it. So it's it's l e I g o n. There is a legion of misspellings out there.

The lee lee lee lee again. I be be careful where the eye is in that name, because it it may jump, out of your view, but, anyway, yeah. So it's it's great talking to you, Sean. And, as always, and, keep in touch.

Doug just said you weren't clever, and here you are coming up with all these, you know, clever puns. Yeah.

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

Absolutely.

And you can find me on Twitter. Still, I am active there. Network underscore fill. You can 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 of a episode idea for a podcast. We'd love to hear from you. Email us at telemetry now at kentech dot com. So until next time, thanks for listening.

Bye bye.