With recent high-profile software supply chain breaches and President Biden's Executive Order to improve the nation's cybersecurity, there is an increase in the urgency for businesses and governments to move to DevSecOps.  How shall your enterprise integrate security with its DevOps process?  Today on the show, Will Kelly outlines his approach to transforming from DevOps to DevSecOps.

What's going on, everybody? I'm Will Button, the Lone Ranger host for today's episode of Adventures in DevOps. But I'm not solo. We've got Will Kelly, returning podcast guest, here to talk with us today. And we are talking about the transition from DevOps to DevSecOps. Will, thanks for joining us.

 

Thanks for having me, Will. I'm glad to be back.

 

I'm excited to have you back and looking forward to this chat. So give us a high-level overview of DevOps to DevSecOps transition.

 

I'm still doing a lot of writing for RedHat's open source.com. So last spring they published a collection of my articles in an ebook about DevOps to DevSecOps transformation. Interesting. DevSecOps for the people here is sort of sniffing around it right now. It's bringing security further closer into DevOps. You're bringing it into the DevOps processes that we all know and are building towards. So it's addressing code quality, security, and reliability assurance. It's adding a lot more automation, bringing in continuous security and compliance. that have to adhere to Sarvane's, Oxley, PCI DSS, and other similar compliance programs are candidates for DevSecOps. Additionally, the way I view the DevOps market right now, it's always constantly evolving, it's always constantly changing. Eventually, I can see in the next couple of years where the DevOps discussions a lot of organizations are having right now are just going to be subsumed by DevSecOps. And that's going to be other movements that are pushing towards that software supply chain. and just the general breach of the week that we've been, that we seem to be having over the past couple of years. The other important thing that I see about the move to DevOps, DevSecOps is also, it's another step in that DevOps cultural transformation. Just like you can't buy DevOps, you can't buy DevSecOps and security. You have to bring your people along. with it. And I'm not talking about just your developers, just your sys admins and operations. I'm talking about the whole team and the team that's and the business people that support them.

 

Yeah, I kind of like it. At first, when I first heard the term DevSecOps, I wasn't really a fan of it. But over time, I kind of started to like it because I think it highlights the need for security and bringing it into the DevOps realm. We've tried to do security. You and I have both been doing this for a long time. We've tried to do security as a bolt-on after the fact thing. and it just doesn't work. And so I really like the approach of just saying, hey, this is what we do. This is how we do it. This is how it's automated. And then it just happens automatically. And I think that's really the only way we're going to see a long-term embracing of security and making it something that happens on a regular cadence instead of manual lifts after the fact.

 

I definitely agree with you. I've come from a far more traditional software development and security background, and the dance is just bolting on security at the end, or they're gone. I've had the opportunity to see DevOps and DevSecOps in the commercial and public sector both. And the really interesting thing about DevSecOps adoption is there are actually elements of the government that are making real inroads into it. And that's because there are security requirements, there are compliance requirements, a plan than the commercial world. So, security needs rise, people try and do more with less. as more people move to the cloud, to DevSecOps future. And that's why I say the DevOps conversation as we know it right now, going away over time where we're just gonna be talking about DevSecOps instead of DevOps.

 

Yeah, it's a good point. As we write more and more code and build more and more applications, the number of security tasks that we have just increases alongside that. And automation is the only way we're going to be able to stay on top of it.

 

Exactly.

 

Jonathan, what's going on?

 

Hey guys, I thought I'd crash your

 

Good

 

party

 

job.

 

here and see how your security is or if I can just kind of sneak in here.

 

Well, welcome! Happy to

 

Thanks.

 

have you here.

 

Yeah.

 

I was having some hardware problems.

 

No, were they security related?

 

Probably. USB ports were flipping out and doing all sorts of crazy stuff and I had to reboot a few times and then finally I'm here.

 

Nice. Well, we're excited to have you. We're talking about the transition of DevOps to DevSecOps.

 

Yeah, I was just looking at the article. Interesting topic.

 

It is. What are your thoughts on it?

 

Yeah, so I've actually been asked a few times about this and my feeling is that DevOps should include sec, but if it doesn't, then, you know, if calling it DevSecOps adds some visibility or some focus, then by all means, call it whatever you want. Call it DevSec customer children. I love my wife ops. If you want, I don't care. If it helps you do something

 

Yeah.

 

useful, call it that.

 

I wrestled with something similar to what Jonathan had just said because as somebody who's written on a lot of these ops related topics for publications, we've certainly hit in a time of peak ops in our industry

 

Hehehehe

 

where everything

 

Heheheheh!

 

is an ops.

 

Yeah.

 

There's good ops, there's agile ops, there's dev ops, there's dev

 

ML Ops, AI Ops. Just goes on and

 

And

 

on.

 

the list goes on. However, when I took a step back after being just battered by those trends, there's a case for consolidation. And I sort of subscribe to... The, the, the view of it is that DevOps is a lot more flexible, a lot more adaptable than the old ways of doing things. And that's why I see the DevOps and DevSecOps are eventually gonna eventually gonna come together. Operations teams and in DevOps teams. It behooves them to look at the best practices that are coming out of those other ops ways of thinking and seeing how they can improve their own practices. I disagree that we should all run down the path to put in the next great ops trend, but security net. the importance of that, the growing importance of that, the changing threat factors, I see as making DevSecOps stand out from just the peak ops world that we're in.

 

Yeah, security definitely deserves its own special attention. Like you said, it's central. No matter what other ops things you're doing, whether it's like you said, GitOps or MLOps or whatever, you need security and all of those. So security is pretty central. I think there's a strong argument there.

 

Okay.

 

I think one of the benefits to actively addressing it, I was talking recently with someone, and I'm going to leave the company name out because I think I remember who I was talking to, which is kind of weird, but I can't be certain. They're subject to PCI compliance and they have actively embraced doing a DevSecOps type movement and for their PCI audit for the last couple years. They've said that it's been a breeze because every time the auditor comes in, they just point them to their automation pipeline and say, here's what gets done with every build. And then the auditor will be like, well, who has access to this? Well, no one does, just the automation pipeline. And it's actually simplified their life for doing PCI audits. to the point where they just point the auditor to their tool and their processes and go on their way. And if you've ever been through a PCI audit, that's normally not the case. Usually it's a couple months of meetings and arguments and negotiations followed by pleading and begging, and then they finally issue your certificate.

 

I was on one PCI DSS audit. and it left a nice little bruise on my forehead. Just left a nice little bruise where it was... Every... I mean... I'm not a developer, but every... compliance project I've ever been on, every audit I've been on, has been incredibly painful for the entire team and the managers and the stakeholders and the executives above them. So when you look at the automation benefit of DevSecOps and the simplification, especially just where we're at right now with the pandemic. A lot of teams are working remotely. It's been a lot of layoffs, unfortunately, the great resignation. That automation of security, it has more benefits just outside of just that compliance. program and the smart organizations, the forward thinking ones, are going to tap into that too. Gain more of a market dominance, more of a market leadership position. There's still a lot of cultural changes and a lot of internal education and outreach, just like there was for the move to DevOps. Because unfortunately, whether the economy is good or bad or in between, the development team hears the word automation. There's inevitably going to be somebody who's going to go, do I still have a job?

 

Yeah, that's a really good point that I hadn't thought of, just onboarding new team members. If your security checks and constraints are automated, it makes that process a lot easier and results in less training and also less risk for the business because you don't have to try to remember, did I tell the new guy that we have to do this?

 

Yeah, there's a lot of work around that. I mean, the first step with any real, that first move in the DevSecOps, I've always tried to point to that analysis. education and training. Because the other thing is there's going to be executives who when they see the word automation they go, ooh, cost saving, ooh. You have to educate your developers, your ops teams, their leads, the executives over them of exactly what automation is, what it isn't. What the time savings. and the potential cost savings are going to be in those compliance audit scenarios, but as well as the potential positive impacts to the quality and the security of the software as it's delivered. There's that education and training part also. Security has to become everybody's job in the world of DevSecOps. That's not just the developers, that's just not the operations team and sys admins. I'm also talking the QA team, I'm talking the technical writers, I'm talking even the people who are selling the product. DevSecOps gives corporations and companies, smaller and large, more of an opportunity to drive home a security story that is real and can be validated.

 

So do you think that education process is different depending on the audience? Like is it different, the story you tell to your executives, is that different than the one that you tell to the development teams or maybe not different, but highlight different,

 

Yes,

 

present the story in a different way?

 

yes, yes, yes, I do. I'm, it's not traditional change management by any means. That this isn't something that you're going to want your company's change management team to push through. The industry will say, you know, it's a security advocate that pushes these stories and these changes. I still believe that there needs to be that DevSecOps advocate. Person can be the security advocate as well, but you need somebody that has trust of... the internal teams, you need somebody that they've worked with, you need somebody who .. .. hasn't been sitting on sort of the sidelines and just watching things, getting out there and talking to the developers and the ops teams and advocating for that change. Then you need to sort of distill another version of that story for the executives that are higher up the food chain. Even if some of them are technical, they're not necessarily gonna, since they've been a down in the weeds programmer. You're gonna wanna, before you go talk to them, is understand what their pain points are. Is the CTO worried about? software quality, the number of bugs, is the CISO concerned about compliance programs, is the CEO just plain worried about delivering software on time that customers will buy? discussions, develop those relationships, because you're gonna wanna be able to build the feedback loops of when things are working right and when things are working wrong. And as DevOps has changed, so will DevSecOps change. There's gonna be other discoveries, other lessons learned, and you wanna be able to communicate them on a continuous basis to the people who are of interest. Sometimes when you're dealing with that executive level audience is... Look for ways to improve your reporting on security. Rock from your DevSecOps pipeline. Build dashboards. Take moves to increase observability that puts out data in a format that's going to resonate with them. take that level of sort of reporting off of the development teams and see where you can automate it. So if an executive wants to take a look at how things are going, boom, just go right to that dashboard that's updated.

 

Right on. Jonathan, I see you nodding your head over there. Anything you want to add to that? Okay. So, we're going to go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and go ahead and

 

Not really. I mean, I agree with what he's saying. I do have some questions, but I feel like I could jump into them now, but it's a change of direction. So my big, I deal a lot with small teams and small companies where

 

Mm-hmm.

 

security is often an afterthought. You know, they're, you know, especially if you're just an early stage startup, you... maybe almost intentionally don't care about security because your goal is, I need product market fit. If we leak the three passwords we have right now, nobody cares. Ha

 

Hahaha!

 

ha

 

hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahah

 

ha. But eventually you do start to care because eventually you have thousands of passwords and you start to have credit card numbers or whatever it is that relates to your business. How do you go, and I know that's sort of the topic of this article you shared with us, but how do you go from, like security has always sort of been a, yeah, one day we'll get to it idea, to okay, now we're gonna make an integral part of our business. Like what are some first steps? Because it just, I mean. I think to most people, most CEOs, most engineers in these situations, it seems so overwhelming they don't even want to think about it. Can

 

Thanks

 

you break

 

for

 

it

 

watching!

 

down? What are some simple steps you can do to start in the right direction?

 

I guess that's a really interesting question. I think you have to take a step back when you're planning your development environments. It's trying to have an eye for growth. It's an easy assumption to make that the early stage startups are rolling their own DevOps tool chains from open source. along the way, start trying to pull in some of those open source security tools that are out there and put them in your tool chain and start to experiment with them. early. It's easy to be reactive in a startup, but they also have the advantages of being able to pivot. When you're hiring developers and sys admins, look for that DevOps or DevSecOps experience. Look for people who have a track record of successfully building out development lives inside your company. Start small and build out. Stick to open source. So you're not going to wake up one day and all of a sudden you got the one big marquee customer that can make or break your business or... landing them is going to be that one account that's going to make your potential series be invested and go, these guys got game. It's built slowly. It's easy to ignore, but when it comes to security at that stage, but... build that culture to be able to pivot. Another argument is try and build that security culture from the beginning. Instead of just having those thoughts of DevOps, just jump right to DevSecOps. If you're building with containers, look for open source container security tools where you can automate, look and start building it out gradually. Most of, so many startups are always tweaking their tool chains anyway. tweak it with security tools.

 

Yeah.

 

And then as you get larger and larger, you can always go back, document, and then iterate and build out maturity. Startups can use that culture of iteration and pivoting to their security advantage, even if security is not at top of mind.

 

Mm-hmm. What are the first areas that you would recommend a company look at? I mean, I could see somebody saying, oh, we're gonna start running Dependabot on all of our repos. Actually, GitHub kind of does that for you for free these days. Or we're gonna start running some DAS tools. But there's so much they could do. I mean, if they start running security scanners on their Docker images, but all their passwords are stored in plain text somewhere. Are they focusing on the right thing and how do they know what to focus on?

 

That's a challenging question. I mean, inevitably at the early stage, you need to take stock of somewhat of a security roadmap. And that security roadmap, there's going to be the obvious. I need to, you know, I got secrets. I need to protect passwords. I need to, I need to talk to lock down. Scanning of containers is an easy win. The balance, those early stage startups have to find is not going down the security rabbit hole. So it started at low hanging fruit. that could slap somebody upside the face and embarrass

 

Thanks for

 

them

 

watching!

 

Yeah.

 

and build out from there. The other thing early stage startups need to contemplate is... farm out some of those security tasks to their more senior developers to build out. If their CTO is still a CTO who's coding every day and there's not the budget for a chief security officer or even just somebody focused on cybersecurity, just delegate those tasks out. Focus on open source tools. Focus on learning. Focus on that cross-pollination of expertise. If you bring in, if you hire a developer from a very strong container background who has that container security expertise, and he's willing to dive further into it, or he already comes from a shop where they did a lot of that, a lot of that work, that guy becomes your point person for container security. If there's somebody else that has a grounding or an expertise in cloud security, that becomes that cloud security point person. The trick is, it's just try and document those efforts even at just the note stage and you know in

 

Mm-hmm.

 

a been done. So for that day when you do have to mature, when a customer says we need you to become Sarbanes Oxley compliant, we need you to get SOC 2, you already have a start.

 

Would you recommend that a company hire like a comp, one of these early seed startups, they're getting, they're starting to think about security. Would you recommend they hire like a security audit company to come in and do a deep audit and point them at the things they should be looking at? Or should they try to do their own homework first? What's the right order of operations there?

 

The right order of operations is building your security expertise in-house first. When you're building that minimum viable product, when you're planning that roadmap. You know it start laying the ground for your security the investment that heavy investment in a security audit Should be customer driven. Let's say if that startup is targeting an industry where Stock to is a necessity and they know that investment in that security audit is bankable, is worth it, and lets them in the door of potential future customers, it's definitely a financial decision that they should consider, but it needs to be business and sales driven at the earliest stages.

 

I like that. Bring the biz in, so now we have biz dev sec ops, right?

 

hahahaha

 

Focus.

 

Well, I think there is a biz dev sec ops actually.

 

I'm sure there is. I've certainly seen

 

Hey,

 

biz dev apps, so.

 

it's a peak ops world.

 

What are some mistakes that you see companies make when it comes to implementing DevSecOps? What are the common pitfalls?

 

I think the common pitfalls I've seen in the industry and from people I've spoken to during the course of the articles I've written, there's still that misconception out there that you can buy DevSecOps. You can buy just like the misconception of buying. DevOps, there's a lack of the focus, there's a lack of focus on the people. There's a disregard of any sort of a maturity model. There's going to be the pre-DevOps world, there's going to be that early DevOps, DevSecOps adoption, then there's going to be more of a full transition until an organization is full DevSecOps, there's no... they missed the consideration of the methodology part, that maturity part. It's not a turnkey effort at this time.

 

Yeah, okay. So we can't just adopt Scrum and say we've done DevSecOps. We have to actually think about it a little bit.

 

Or, or, or yeah, we're agile. We work really fast.

 

Yeah.

 

Not on the right things, but we're really fast at them.

 

Exactly. And that, you know, I've been in an organization or two where that was their definition of agile.

 

Yeah.

 

Right? Absolutely.

 

We're really fast. Um, the other thing you can't forget with, with that second is the people element, that outreach, that education, that managing of the changing expectations and the real and implied power that that that that can sometimes affect inside an organization.

 

Yeah, it's kind of funny how this just resonates with the same conversations I remember having when DevOps was really starting to gain traction and it's, you know, it's not something you can buy. It's a cultural movement. We have to start internally in the team talking about what's important to us, how do we implement it and then moving steps forward to that. And then... spreading that message out to the teams that we support and interact with and moving forward that away. And it's an iterative approach. It's not something that you can just say, oh, corporate's announced we're doing DevSecOps and right click save as and then move on to your next ticket.

 

I think what also sort of hampers that DevOps, the DevSecOps transformation is the bad reputation that change management teams have inside some organizations. Where regardless of what your personal feelings are on the state of change management, there's plenty of developers and technical people who see them as more business prevention. That's why

 

Okay.

 

I always recommend that you have to build those advocates. The teams have to be pushing the transformation and doing the work rather than sort of being on a zoom call while somebody is pelting PowerPoint slides at them, this is what we're going to do. Cause that helps build buy-in. That helps. draw on that expertise because Dev Tech Ops, just like Dev Ops, you could get five developers on a team from five different places and they'll give you probably five different definitions. So when you get those people together under the right management, the right leadership, that lets you cherry pick and mold and push forward with the DevSecOps approach that is right for your organization, not what a vendor is trying to shove down your throat.

 

Yeah, you know, you've said a couple of times and I think it's worth specifically highlighting, um, of building advocates outside of your team from people who are, um, going to be impacted by this

 

Thanks.

 

and not only building them as advocates, but also understanding what their needs, goals and desires are and seeing how those overlap with the, the changes that you're proposing. Because that's really how you get a cross-departmental movement really going forward when everyone sees what's in it for them.

 

Sometimes your biggest DevSecOps advocate could be your sales team.

 

Yeah.

 

And that in some cultures, where sales and development are natural enemies in the wild might be hard to take it first. But the simple fact is, if that salesman is able to close more deals and deliver because you're delivering more secure and more compliant software, that's somebody who's attached to where the money is making the money for the company. can have a lot more push and punch than maybe some assistant vice president that nobody really knows what they do.

 

Yeah, that's a really great point. If you can arm your sales team with something that they could, with a security related fact that they could use as their sales process that helps them close more deals, you're going to be their hero and you're also going to have some very vocal advocates in the rest of the organization as a result.

 

And then you bring in your product marketing and your product managers who then Who are then in a better position To highlight those security related features and create that security focused Messaging, you know that's going to resonate with your customers

 

It falls once again, as things commonly do, that a large part of what we do in DevOps and DevSecOps is not actually the technical aspect of it but the communications aspect of it.

 

And we touched on that the last time I was on the show. In the end. DevSecOps, it's another step in improving collaboration as well. It's a, we can sit here and talk all we want to about the security and the technical aspects and the improvements that result from it, but it comes down also that so much of this stuff is a people gain and it

 

Yeah.

 

doesn't matter if you're an extrovert or the most introverted engineer. who doesn't want to talk to anybody. It's still trying to break down those silos. It's still trying to automate things and get information across that took a couple of extra steps before that may have taken some people extra time that can now be devoted to more strategic and money-making tasks that you didn't have time in a pretty dead dev sec off. world. There's always going to be that bad experience of the last audit. I've seen those bad experiences last linger in an organization for months if not years. A victory with DevSecOps, a victory with a move to DevSecOps after that is, those stories become less and less. or those stories don't become as horrific as it may have once.

 

For sure. Cool, anything else we should talk about in the transition?

 

Well, I think the other thing that organizations have to look to with the transition is all the new attention on the software supply chain and software supply chain security. The future of that with the automation requirements that are going to come from that and the security challenges. It's another, it's another future home of DevSecOps practices and tools. Whether it's the automation of container scanning, whether it's, whether it's the automation of the generation of software builds of material, it's, it's going to be another part of the DevSecOps future in my mind.

 

Yeah, and there's a lot to take on, so don't feel like you have to solve all of the problems at once. You know, just pick one thing and chip away at it.

 

And that's where at least DevSecOps is, you know, it's set up for organizations to do that. You can set out a roadmap, you can set out a maturity model, whether you're that early stage startup or a large enterprise that's trying to shore up their development security practices, you don't have to do it all overnight. You can set a roadmap, you can set priorities, and you're in a position to iterate on that and pivot as necessary. the great, that's perhaps something that not enough people talk about when it comes to DevSecOps. It's the adaptability of it because security challenges are not one size fits all.

 

Yeah, and in many cases, when you start addressing those security issues, it's likely that that just teaches you enough to show you that you actually have other security issues that you didn't know about, and so it's okay to change.

 

Yeah, there's always that security rabbit hole you're going to find. But that comes down to with the development team and the security team, setting those priorities and deciding what needs to be tackled right now and what can be deferred to a backlog.

 

Yeah. Anything else?

 

Nothing else comes to mind.

 

Cool. Should we do some pics?

 

Sure.

 

Alright,

 

Awesome.

 

Jonathan, have you got a pick for us?

 

I have two picks today.

 

Oh, bring him on.

 

Yeah, I know, this is gonna be exciting. Where did it

 

Yeah

 

go? I had it ready. So my first pick is, there's this podcast I've been listening to, sort of, called Adventures in DevOps. And

 

Ooooooh!

 

Whoa.

 

they had an episode a couple, a few weeks ago, episode number 121 called Reducing On-Call Engineer Burnout. with a volunteer management infrastructure. And I just wanna pick that episode because we're doing that now at the job I'm at. And I'm on my first, I'm the first person on call for the week. So I'm on call and we're using the strategy discussed in that episode, episode 121 of Adventures in DevOps. So that's my first pick. Is that okay? Is it okay to pick the show itself? Ha ha ha. Ha ha ha. Ha ha ha.

 

Absolutely.

 

Ha ha

 

Good luck.

 

ha.

 

I think that I actually should be like a rule going forward now that every so often we have to do the old hashtag shameless self-promotion.

 

So that's my first pick. And my second pick, if you're new to the show, you probably haven't heard me talk about this. If you're a long time listener and you've heard me say, and you can tell from my accent that I'm not from Europe, even though I live in Europe. I'm American, I

 

Wait,

 

was born in

 

what?

 

Oklahoma.

 

What?

 

I know, it's crazy. I was born in Oklahoma, I went to high school in Kansas, so I'm a Midwest boy. But I live in Europe now for the last seven years. And there's a few things about home I miss. Not very many. Well, there's a few,

 

Dairy Queen.

 

not counting. No, not for sale.

 

I

 

Although, man, a good old American milkshake would hit the spot. The milkshakes here are just so runny and they're just not the same. But I finally broke down last week and ordered a case of dill pickles. So I'm picking dill pickles because I haven't had a good dill pickle in so long. So

 

Huh.

 

there you have it. Adventures in DevOps, episode 121, and eat some dill pickles.

 

and self-heckle.

 

Alright. What about you Will, have you got any picks for us this episode?

 

I read the book Build by Tony Fidele when I was on a business trip. If you want to get sort of that behind the scenes look at how the iPod and a lot of those seminal Apple moments happened around it, I highly recommend the book. He takes a very non-academic perspective about product development, which I liked. And could my second one be a shameless self-promotion?

 

Oh, absolutely. Highly

 

That's the

 

recommended.

 

best kind.

 

Oh, I've got one then, so you better hold on. You better hold on. I was laid off last week. So if

 

I don't

 

anybody

 

know.

 

is looking for a product marketer or content marketer with a background in DevOps and cloud with a wide body of work published on those subjects, you can find me on LinkedIn or on Twitter.

 

Yeah, for sure. We will include your contact details in the show notes. And,

 

I would

 

um,

 

appreciate that.

 

yeah, and yeah, it's a, it's a great fit because from listening to the podcast, you already know a little bit about Will. So. give him a shout and see what comes out of it. All right, my pick, I'm just going to pick one this week. I've read a book called Endure by Cameron Haynes, and it's super cool. If you have read Can't Hurt Me by David Goggins, it's along that similar vein where it just

 

Bye bye.

 

makes you want to throw everything down and go for a 40-mile run, even though you've probably never run past your refrigerator in the last 10 years. But it's super, I found it super motivational. He's a guy who just grew up in Oregon, small town, loved to go bow hunting. And the book is about his journey of just becoming a better bow hunter. And I found it pretty inspirational. And so yeah, Cameron Haynes, Indoor, that's my pick of the week.

 

Are you

 

That's

 

going

 

all.

 

to be

 

Thanks

 

trying

 

for watching.

 

out for the next Hunger Games then?

 

Dude, I would love to. I'm

 

The

 

thinking

 

David

 

like,

 

Pabon story.

 

what's that? There's like the American Ninja, where it's like an obstacle

 

I live

 

course.

 

in Europe, I don't know anything about that.

 

It's like an obstacle course TV show. I'm thinking that, but along the way, you know, you have to... Do dexterity tasks like shooting at a target with a gun or a bow. I'm thinking that's the route to go.

 

Awesome.

 

Yeah.

 

The David Coggins story, his story is just wild.

 

It is, I love that story. I can't help but think, you know, he's pretty hardcore and he's definitely motivated, but I kind of feel like there's probably a need for him to talk to a therapist too and just like, you know, maybe address some of those issues that are driving him to run 200 miles across the desert instead of talking to a therapist. Maybe there's a happy medium there. Maybe it's just me. I don't know.

 

Well, no, it's really funny. I live and work in the Washington, D.C. area, and years ago I had a client who was a farmer. Navy SEAL and he was in his 50s or 60s at the time. His joke was he hadn't worked out in 15 years since he got out of the Navy because he did all the working out he needed to do when he was in the Navy.

 

Right?

 

And the guy was still in excellent shape and he's just like I did all of that you know because I don't have to do it anymore.

 

I checked the box. Let's move on.

 

I've exercised enough because I've swam, I've run,

 

Hehehehe

 

but the David Hagen story takes that many more steps. And then

 

Yeah,

 

I think

 

for

 

in Recurrent,

 

sure.

 

he's like a backwoods firefighter or something, like one of those smoke jumpers.

 

Yeah, he is, he

 

Yeah.

 

is. I bought the book and gave it to my youngest son because that's what my youngest son does. And so I'm like showing him a picture and like, if you ever see this guy on one of the sites that you're working on, get a picture with him for me.

 

Yeah.

 

Hehehehe

 

All right, cool. Well, I believe we have an episode. Will, thank you so much for coming on. It was a pleasure chatting with you and good luck in your job search.

 

Likewise.

 

And if you're looking for someone with Will's skills and talents, be sure and hit him up. And

 

Thank

 

I think

 

you both.

 

that will be good.

 

Why don't you just shout out your Twitter and LinkedIn handle just in case somebody isn't at a place where they can easily look at the show notes.

 

On Twitter, I am at Will Kelly. And on LinkedIn, I'm at LinkedIn.com forward slash IN forward slash will Kelly.

 

Super simple. Will Kelly both places? Awesome.

 

Right.

 

Excellent.

 

Thank

 

Right,

 

you both.

 

All

 

look

 

right.

 

forward to next time.

 

Thanks for another great interview session. I enjoyed my time.

 

Cool, see

 

Likewise.

 

you

 

Thanks,

 

guys.

 

guys. Thanks.

 

Cheers.

 

Bye.