how to improve the hiring process w/ nate taylor

full transcript

auto-generated from the audio, so expect a few typos. the audio is the source of truth.

Hello, hello. Thanks for listening to Guidance Counselor 2.0. Listen, I want to give you a quick rundown of what this podcast is and what you're about to get into as you listen to these episodes. We had Guidance Counselors in middle school. We had Guidance Counselors in high school, but we didn't really have Guidance Counselors in college and now as professionals, we don't really have anybody to turn to, to ask a quick question to learn something about the job search or to navigate your career. And so that is what I want this podcast to be for you. I want it to be a tool for you to navigate the job search and your career.

So that being said, I hope you enjoy this episode. And if you need to reach me, Taylor at vaco.com is how to get in touch with me old fashioned email social media at t s and t d e s s e y n. And finally, please rate and review this in the app store because I want this to be discoverable for others so they can navigate their careers. enjoy the episode. Give the people what they want. Who are you? What do you do? And we'll go from there. Yeah, I'm Nate Taylor. I'm a one of the software engineering directors at Flutterll site. I have several teams.

A lot of all of my teams do work that gets things on the platform, but none of the public users will see any of my team's code. So I do a lot of work with authors and the author tooling as well as I have a couple teams that are dealing with the metadata of our data. And I have one team that does Taxonomy, which was a word that I had to learn when I came to Pluralsight. And there is a Taxonomist on there, which was a role that I learned about when I came to Pluralsight. But yeah, so a lot of stuff around what our content is, how do we get it from idea to author to on the platform?

And then I also co-organized a conference here in Omaha called ConnectaHA. that's we're working on getting planned for this year in person because we tried virtual and it was not as much fun as a conference. And then those all kind of pale in comparison. I'm married, I've been married for 21 years. I've got a 20 year old daughter and a 18 year old son. And way too many pets to list here. That's awesome. So Alicia, it's great to see you, your lawn. It's always wonderful to see you. So Nate and I were chatting before we went live and I said, Nate, man, what's going on?

Like, cause Nate, if you don't follow Nate on LinkedIn, I'd highly recommend it, especially if you're a hiring manager or, I mean, a job seeker for sure, but definitely a hiring manager. Nate posts a lot of great things. And so I was, I was talking to Nate and I was like, man, like what, what you got going on? And Nate talked about, Nate talked about three things we're gonna talk about today. So the art of reading resumes is a hiring manager. We're gonna talk about eliminating qualified and unqualified candidates, but also what makes a qualified and qualified candidate. And then also the ongoing conversation of, do we take somebody that needs ramp up time or do we take somebody who doesn't need ramp up time?

So those are the three topics we're gonna come into today. Alicia's funny today isn't taxonomy when you take a database stuff and preserve it and hang it on the wall. Yeah, Alicia, good job. You got it. That team's name is actually taxonomy and ontology and we interviewed someone and they thought we said taxidermian oncology. And we thought about building, we thought about getting shirts that said, taxidermating oncology. But yeah, that's unbelievable. I would highly recommend that. I will buy that shirt. All right, so Nate, let's jump in the first thing. So let's talk about resumes, right? So I think the thing is that we talk about all the time is hiring majors, looking at resumes for seven seconds.

I think that may be a more recruiter thing. But talk about your process when looking at resumes. What do you like to see in resumes? Yeah, I like to see, I like to see the problems that people are solving. And by that I mean, like if you're applying for a position, it's fine if you list your text acts, that's fine. Like I'll look at that. I think there's more creative ways personally that you can work that in. But what I don't enjoy I guess is when I see bullets like I worked on an agile team doing two weeks sprints. I'm like, oh, okay. That doesn't tell me much about an agile.

Right. But if you tell me that you redesigned or re-implemented the front end and that helped save the user time or made it easier, then now I see that you're starting to understand that software isn't just the code you write and the ID. It's trying to solve a problem. And so sometimes even, I say paragraph form, but short paragraph form. So not long enough that I need a TLDR at the end. But a couple of sentences telling me what you did in this job description can be better than 10 bullet points. And you can work in things like I used React and a design system to create this front end that solved this problem for this type of user.

And now I learned a lot about you. And so that's something I look at. And that's not to say that if you don't do that, I don't read your resume. I still read all of the objectives and the tech stacks and those kind of things. But those make it a little bit easier for me to recognize that you understand your writing software to solve problems. And it gives me a little bit more insight into who you are than just here's a list of bullet points. Well, and then what did you say earlier off, and then a few more people time to in Christina's great to see you.

Joshua goes really cool to see on LinkedIn from different perspective. Conversations that Pluralsight is leading the charge in educating developers and putting their money where their mouth is and developing junior engineers. Absolutely. In a LinkedIn user, what's going on from Texas? I love it. So what is the one thing you said though? You're like, like, I don't, what would you say, off air about the time looking at a resume? Oh, yeah, I think the 30 seconds is a lie. I mean, I try to read every resume. I don't sit down and read it like a book or anything like that, but earlier this year, I had seven openings.

And so every morning I would come in, I would get somewhere between five and 30 resumes, maybe more over a weekend. And that was my first thing was, let me go through each and every job posting, let me look at every single resume, because you took the time to submit a resume, I want to hire a person and not just some robot writing code, and so I wanna look at every single resume. And that's not to say I read every single page of every single resume, because some of them get three, four, five pages or whatever, but I do wanna read, and so I will start, there's certain things I look for.

What's the main thing? What's the main thing? Like if there's one thing a person could take out of the show this morning when it comes to resumes, what's the one thing they have to have? That's a good question. I think I can't limit myself to one, so I'm gonna say two. And one, the main one is I wanna know, do you know how to code? Or can I assume that you know how to code based on your resume? So that doesn't mean I'm looking for a React person and you have Angular, you're out, but maybe you can make that transition, right? So I'm trying to figure that out.

And then secondarily, and this is not a close second, but secondarily, I do wanna see how much experience you have because we do have different levels, right? I have an early, an entry level, I have a mid-level, I have a senior, and I'm trying to figure out where to put you, and that will help in the interview process. So if you've only got six months, that doesn't mean we won't interview you, but if I tell the team that this is a senior person and you've got six months, you're probably not passing that interview, right? Because they're gonna be like, like, oh, no, there's no way, right?

Sure. I tell the team, this person has six months, and I think they'd be a good candidate for us to develop. Then they'll look at the resume, they'll look at the interview process that way. So I do try to get an awareness of that. I can't remember. I know I notice things like schooling, but it's never factored into a decision at all, ever. Other than sometimes, I'm like, oh, that's where I went to school. That would be fun to interview this person, right? But that's about as far as it goes. Yeah. Oh, that makes sense. Question coming in from the chat today. question are you okay with job seekers have gap in their employment history.

I'm interested in your thoughts, especially with COVID. And now I'm going to say this on one side, I would say if you've had unemployment as a developer during the boom of the developer error, I would say that would maybe some red flags. But Nate, I'm curious to hear your thoughts. Yeah, I don't, I don't know that I necessarily have paid attention to that. So I mean gaps don't necessarily bother me. I'm trying to look at what your total experience is. We have had some positions, not all of our positions, but some of our positions we will sponsor visas for. And there's often gaps there, right?

Is there going back to school or something like that? And so I will look down and say, oh, before they moved to the US, they were an engineer for five years, and then they've been off for three years while they're getting additional education, whatever. I'm like, yeah, like they still have five years experience. We might have to teach them what React hooks are, or we might have to teach them about something like that, but at least understand how to program. And so yeah, that doesn't necessarily bother me. It's definitely not gonna be something that eliminates you from contention in my book. I love that. So let's, so then anything else on resumes for move on at all or just the general like, you know, standing out in the resume or any process.

The only other thing I throw out is a resume should be there to tell your story, right? And so not just what you've done, but also what you wanna do. And so that doesn't mean less to every single technology because there's for sure things that you don't ever wanna do again. So don't put that on your resume. Craft your resume in a way that helps me understand that you really like working with the user or you really like to be that engineer that is super deep on a technology and they're the expert we come ask you questions. It's not, I mean, it's still telling the truth.

It's still telling about yourself but it's crafted in a way that helps convey that story so that I can make sense of it and go, okay, this is the type of person that Taylor is, that you know, this is what he's trying to do next. Well, and I think going back to what the storytelling versus like the bullet point, like if you say, hey, worked in an agile environment, had two weeks sprints, like that doesn't say anything, right? Let's talk about your project, right? Hey, listen, we took a project that was very behind, it was heavy waterfall, we moved it to agile over small increment.

You know I'm saying like give more information and tell the story then just then just a bullet point Line item doubt because that's that's that's huge Alicia comes in yes your experience is a bunch of dots Your resume is how you number those dots to draw a picture if you don't do well It'll end up scribble scrabble. I also know what you're talking about because you had to connect the dots with that drawing thing back in the day I love that analogy a more thoughts Nate. Yeah, I was just gonna say the agile thing. It reminded me of, you don't have to have the same, if you wrote, if you did agile on every single one of your last 10 projects, I don't need to see that 10 times, right?

You've done C sharp on every single one of your projects. That doesn't, you don't have to make that a separate bullet point, right? Be judicious with the space you're using. Let me know you're a C sharp developer and then focus on something else on the next job posting or the next job history. Yeah, I love that, I love that. So, so, so let's move to the next topic, which I'm fascinated with and kind of your approach. And again, one of the reasons why Nana liked you won your friendly guy too, you have a lot of great thoughts. And so let's talk about kind of what we're talking about off air with qualified versus unqualified.

And really kind of like going down to the wire with maybe two candidates in the thought process. I think a lot of hiring managers that washes showed now in the future go through the same issues you do, right? How do you as a team, all right, we got two candidates, I don't know, do we rock paper scissors? Like what do we do? Yeah, I think the qualified versus not qualified, I think it starts even earlier than that because from my perspective, there's a lot of ways to eliminate qualified candidates that you might not want to be doing, right? So some of it is, if you have a prolonged job process, you're probably eliminating people that would be come in and do really well, but they don't want to go through all these different rounds, right?

And I'll tell you this Nate, just as a recruiter to a hiring manager like you, I'm having a lot of developers that like two things I'm seeing recently, one, developers are only wanting to go through one interview process at a time. So that's something I'm starting to see now to, um, they only want to interview like with so many steps or less. Yeah. Yeah. I think, um, what our people, business partners have told us is that, that Google, their research shows a maximum of four touch points. Um, and so, you know, I would say that max for sure. Right. Right. Max. Right. Yeah. Yeah. Um, yeah.

So there's a lot of ways you can do that. You could, I mean, the ones that come to mind is, you know, if you send a home, if you send a take home test, some people will take that and some won't. Just because they won't take it doesn't mean that they're not qualified and wouldn't do a good job, right? Exactly. So one of the things that we've been toying with, because we do want to know that you can code. And, but we don't want to be like super annoying about it, right? Yeah. So we're exploring the idea of giving the candidates an option. Like, we'll give you a take home test, if that's what you'd rather, or we can do a pair programming exercise as part of the interview.

And like you would do one or the other. I would choose paired programming because I don't have time after hours with a family. So like I'm just like, let's just crush it during the interview process and let's see what happens. But some candidates would be like, I'd be super nervous to be with someone. Right. I'll take the extra hour after work some time and do it. So trying to give those kind of options. I don't know if that's the one we'll settle on or not, but that's some of the conversations that we're having. So that's some of the stuff that you can do to eliminate qualified people ahead of time, that you don't want to be doing, right?

Right. And that's my concern and has been for a while. I think it's, I don't want to say it's easy, but it's easier to eliminate the unqualified people. Like, okay, this person is not ready for this job. Most of the companies I've been at haven't struggled with that. We haven't hired a ton of people that were a mismatch. But when you're looking to hire people and maybe you've had a posting open for three or four months or something like that, you have to start wondering like, okay, are we sure that everyone we told no to was not really going to be able to come in and work here?

I know. And so that's the struggle. And that's where I think we have to be honest with our own assessments. I tell my engineers sometimes that I'm not convinced that I would pass my own engineering test, right? And so that's a problem because, well, not engineering-wise because I'm not writing code anymore. But if my engineers couldn't pass the interview that they're giving the candidates, then that's not fair, right? Well, so you brought up a ton of great points here. So I'm going to try to be clear and concise so we can hit our last bullet point two in in the timing manner, but I think there's a few things to unpack here.

First off, it's the lack of it's making sure there's not a bunch of gatekeeping going on, right? So like, you know, for example, we can start from beginning, like how, what are you doing from the beginning to make sure that even the job responses, the job posting responses are all getting a fair look, because at the end of the day, like they're not, right? I mean, listen, I'm, I'm, I'm going to be all, I'm going to be honest with you all from recruiting side. we have one job posting of, we get 100, 200 candidates. Like the more junior the role is, the more postings we get.

And it's like Nate said, I'm sure that I've missed out on a good gazillion candidates because we are just like one and done. And so that's the first thing is from a job posting perspective, but then Nate and I talked about wording in job descriptions and how important it is to make sure that you're not writing a job description for a certain demographic, right? The next thing is, all right, so we got those two things done. Now we got to start interviewing. And I love what you said Nate. I truly think that hiring managers should get their engineers to take their own interview. Yeah. I mean, I truly think, because here's the deal.

If your team can't do it, that's a concern. And there's a meme going around on the Internet's right now where it's like, I feel like the tech interview process is the only process out there that's harder than the actual job. Yeah. So I didn't know if you had any thoughts on all that. No, I so a little bit of a plug for my own. In addition to being a director of At-Thrittlesight, I've been an author there for seven, eight years now, something like that. One of my courses is Async, what is it called? JavaScript Promises and Async Programming. And I was reading through some sample questions that some of my senior engineers were going to ask another senior engineer.

And they said one of them was something like what's the difference between a promise and async await and JavaScript. And I copied that and I copied the link to my course and I put it in Slack and I go, I don't know that I can answer this question because they're the same. Like it's syntactic sugar, right? I was like, what are you looking for with this answer? And their answer was like, that's what we're looking for is really like, do they understand that they're both accomplishing the same thing? And I was like, okay, right? Like maybe we can phrase this question a little bit better when you actually ask it, maybe ask it in a slightly different way.

Because here I am, I've got the course on Pluralsight on that topic. And I'm like, I don't know that I know what you're looking for here, right? Well, it's so important about phrasing. Go ahead. Right. Keep on. Keep on. Yeah. So, and I don't, I want to make sure, I don't know if any of my engineers are watching this. I don't think that's a problem we have. Like, I think for the most part, we do a really good job of, of asking questions that line up with our teams. But like you said, sometimes it's just phrasing, you know, because I've been in plenty of interviews as an engineer before where I'm like, I don't necessarily understand what this question is.

But here's what I think and I start answering it and they're like, Oh yeah, that's what we meant. I hear that all the time. I hear that all the time. Like hiring managers, if y'all watch this and you keep getting that with your interviews. Oh, yeah. Yeah. That's what you're talking about. I do this. You're not asking good questions. Right. Because I hear that all the time from developers. Oh, hey, Hey, Mr. Miss developer. How did the interview go? Right? Cause we call all our people after interviews. They're like, I think it went okay. They asked me some questions that I didn't know, but then I like asked them to re-explain it.

And then I did what they did, but it made me feel weird and it's like Yeah, I always So my process is I do a after the recruiter talks to you and kind of gets a level set of salary and all that stuff I do a values interview or you line it up with floralsight values And to me if you're not lining up with the values, there's no point me passing you on to the engineers But one of the things I try to do during that that process is tell them that like one I won't be asking you deep technical questions and two even when you talk to our engineers We're not trying to trick you you won't be writing bubble sort You know any of this kind of stuff like we're trying to figure out You know how what would it be like to work with you on this team on this project?

And so we're gonna focus on those kind of things and I've always told my every person I've interviewed or every every time I've interviewed people not necessarily every person I'm not asking trick questions. So it's not clear then like yeah Let's talk about it because it's not I'm not trying to get you. Yeah, I'm trying to understand Where you're at and how we could work together. Well, and that's what's so key, right? So then so then we kind of go through the process of how Intentional you have to be the interview process between how you're evaluating or your applicants to what questions you're asking to How you write the job description and then to your follow-up and so it's incredibly incredibly important So so I do I do want to kind of move on And this is a fascinating topic that Nate brought up.

And again, I was just like, Nate, man, what you dealing with? And so I like this where we're just kind of talking about issues. And that's what I want for the show. Like we're all doing just the best we can, right? Talking to hiring managers, talking to job seekers, we're just out here just trying the best we can. That's why I love about Nate and his openness. But Nate, so you brought up about how you guys get into the, do we hire somebody who can go now? Or do we hire somebody who could potentially mold in three to six months? So just give me some initial thoughts and maybe some conversations you all have had behind the scenes at Pluralsight about that.

Yeah, I mean, there's no universal answer to that. So a little bit of context, the engineering teams at Pluralsight, we try to keep it for maybe five software engineers. And then we have product folks. We have a product manager, a product designer. We might have machine learning people. But four to five software engineers, a team would be about six to seven, eight people. And so they're deliberately small. And sometimes those smaller teams are newer, right? So they're newer to Pluralside or they're newer to each other. And so that might mean like, no, we actually do need someone that we, you know, we don't have the time right now to ramp up someone because we're trying to figure a lot of the stuff out ourselves.

Sometimes we have a more mature team that's been around longer and they're like, yeah, we can absolutely take on someone. But part of the evaluation for me is we're doing this, is looking at a top tier, one of my best engineers. engineers. If I, if he didn't work at Pluralsight, I could, I could hire him. It's going to take him two to three months. Not to, not to get up to speed on JavaScript and type script and all that because he's got it, right? What's our infrastructure? How do our teams work? What's our product philosophy? All of that's going to take two to three months.

One of my top engineers, right? Like consistently rated high. And so if that's going to take their name, Nope. They know who they are and I will share it privately. But yeah, You're not coming out after my guys. I love it. I love it. Right. But no, I mean, if that's the end for the top folks, right? Like then the minimum it's going to take is two to three months to get someone up to speed. Um, and then someone with less experience or someone that's less skilled or whatever else it could, it could take six months, right? Um, and then as, as you move down from a senior, so, you know, a more entry level person and all those kinds of things factor in, but you start looking at it and it might take me six months to find that top engineer and then another two to three months to get him up to speed.

So now we're talking eight to nine months to find this guy that's already on my team. So the question is, would I rather take eight to nine months to fill this role? Or would I rather find someone in three months and then spend that second month getting them up to speed? And that changes based on team and all these that are different dynamics. But I think it's something that we don't look at enough in the engineering field of like, people are gonna, it's gonna take time to get up to speed. You will not find someone that you can hire today. They start on Monday and they're fully committing and 100% proficient by the end of the week.

It's just not gonna happen. So, so then, so then, man, so then what, like what should companies do? Should companies maybe gear more towards it? Let's get somebody in and train them up instead of waiting for Mr. Mrs. Wright? I mean, I think it depends. So we've done that on, or we as Pluralsight have done that on some teams and some teams have made the decision that know like this is a thorny enough issue that we do need to wait for Mr. and Mrs. Wright. But it's really a decision you have to make, right? You have to think, I guess. I was going to come down to it, right?

Like that's what I'm trying to say. Like you have to actually think and analyze the situation of where is this team at? What do they need right now? How willing or, how experienced are they at mentoring people and with a good chance and all this kind of stuff because it could be a really bad experience if you have people that haven't mentored a bunch of people and you suddenly bring in three new people that they have to mentor, maybe that's a bad experience for them. So yeah, it's looking at all of that. I personally, at this point in time, would err on slightly on the, let's just bring them in and ramp them up.

But I'm just one voice in the interview process with my teams. It's a team decision. And sometimes I'm a yes, let's bring this person in, and sometimes someone will say, well, here's why I don't actually happen to me with my team recently, I was like, yes, and my team was like, no. Yeah. And also again, I wanna give props to Nate and his team. And I know, Nate's not perfect. I know that, but what Nate is doing is he's having conversations, he's being intentional. I think that's all I'm asking for hiring managers to just, hey, listen, do we have the affordability to wait nine months?

If you have the ability to wait nine months, wait nine months, that's fine. But I bet you do not. I used to have a trade off, right? And that's where it goes into the recruiting matching. Like if I send Nate a candidate, Nate and I were to work together, Nate, we should make that happen. But Nate, you know, if I'm working with Nate and I said, Nate, I got, hey, man, I got 60% here. He goes, that's cool. That could potentially be an opportunity. But let's bring him through the interview process. See where they're at. Nate brings him to the interview process. He goes to he they don't have 60.

They have 40. But that 40 is still enough that we need to bring that we need to bring them on. So again, it's just, it's having those conversations and being open and honest. A few more people have tuned in, James, what's going on, Raymond. James has a good question here. James is a former guest and speaker on GC2.0. Do you consider a potential higher for future growth positions or solo the position you're hiring for? Ooh, this is a good one. It depends, right? That's a typical engineering answer, but yeah. Yes, I've considered people where they can grow. I tell everyone, so after I make a hire, I do a quick phone call before they start with them or a quick Zoom.

Just to kind of like, we can talk about some of the things that you can't talk about in interviews, like, hey, tell me about your family. All those kind of things that you don't want to be bringing up because you don't want to buy us or get something like that. And so we talk about that. And one of the things that I tell them, a personal lead me, that's here's how I operate. here's what you can expect to get out of me. I love that. And one of the things that I talk about then, and one of the things I talk about right after they start, is my job as a hiring manager, or as a lead here, is to help them be as successful as they want to be in the way that they want to be.

And so some folks, I want to be a senior engineer in three years. Like, all right, that's going to take a lot of work. Let's get on it. Other people are like, hey, I want to just, I want to know this product inside and out. And so that kind of goes back to that. I'm looking for people. Some people want to grow, you know, and they're like, this is where I want to go. I will hire for that as well. And some people are kind of like, I want to hang out and stay at the spot. Yeah. James goes, a personal read me, that's great.

Can I use that? Get after James, that's it. Well, it's not my idea. There's a lot of them out there. I can post the link to mine on the comments of this video when it's posted. When one will wrap up, yeah, for sure. So, all right. Oh, also going back to James's question, I do have to say, I think for hiring majors too from a recruiter side, I think there is a, we have to pivot to recruit for you. So if you are potentially going to get a higher in two to three months, like you're going to get a position to head count open up, like you need to let us know so we can start sourcing for it because it really is like, you know, you definitely need to, you definitely need give his heads up on the recruiting side.

I would also tell you this, my strategy, I think one of the biggest strategies when it comes to, um, when it comes to planning out and hiring, I think, um, hiring majors who work with recruiting vendors like myself should have a weekly call, a weekly standup call and just see their top candidates. Um, because there's a lot of candidates that, that, that we meet that you probably want to see that you'll never see. So that's just my two cents there. Let's see, Justin goes, I love the intro to working with Readme's. That's a great connection right off the bat with a new engineer. I love that.

So Nate, good job. One thing I want to say really quick, because you mentioned like, hey, do I have nine months to wait, right? And sometimes you do and sometimes you don't. I would say, you know, with the current climate and the phrase itself annoys me, but the great resignation or the great migration or whatever we're calling it, right? Like the chances of you losing someone in the next nine months might be be high as well, right? So it might not just be that, do I have to work the weight for this person, but who am I going to lose while this other team member has to carry more of a load, right?

I think I hate it. It's a little bit doom and gloom, but I think higher managers need to consider that your entire team is going to leave you in a year. And I think if you work on that side of urgency, I think you're going to be OK. And no, that's not the case. But to be honest, as more in a hiring position now than I ever have been, I think my entire team's about to leave me, like, every day. Now, that is not a healthy place to be. I understand that, but I'm always thinking about retention, strategy and thinking ahead because that's just, even the recruiter market, the recruiter market, honestly, I would argue harder than the software market right now because all these companies are scaling up and they need internal recruiters and my recruiters are getting picked off.

So, I mean, if you're not thinking about that now, then it's too late, right? Like you can't think about retention once someone starts looking because you've already lost them at that point. Absolutely. So good. Nate, we're done, man. That was quick. I knew that would happen. Do you have any wise words of wisdom, and you want to wrap up with any just encouraging words for job seekers or hiring managers right now in this market? I mean, nothing, I guess, nothing novel or anything like that. I mean, it really is more of the how you can make that connection and that can be hard over paper or resume, right?

And so that kind of goes back to that telling a story thing. the more of a connection you can make, the better. It's not always gonna work out. Like there's no foolproof universal. Here's how to find the best candidate or the best job, but the connection's important. And so the more that you can do with that. So I'm sure that's a message that you like, right? The more networking you can do, the more connection you can have on LinkedIn, all that makes it easier for everybody. It does, it does. All right, y'all. Well, thank you again for hanging out with us today. I want to give another shout out to Render ATL.

I appreciate y'all time for letting me be a part of your organization. Go connect with Nate. I'm going to post his, Nate shot me as read me. I'll tag you in the live post and if you want to tag it there. But y'all have a great one. Go connect with Nate. He's great on LinkedIn. Tell him you watched the show this morning. And I'll see y'all next week. Nate, stay on real quick, but y'all have a great one. I'll see y'all Monday. Peace. Hey, you did it. You listened to an entire episode and I am very grateful. Because you know why? There's a lot of podcasts out there.

There's a lot of episodes and I myself rarely finished an entire episode. So I appreciate you so, so much for listening. Quick reminder, please rate and review this podcast in the app store. I want this to be discoverable to others. And the only way that happens is if you take the time right now and rate and review it, please, like right now. Unless you're driving, then don't do it. So thank you again. If you need to reach out to me, Taylor at Vaco.com or at T.S. and on all social media handles. And I hope you have a fantastic day.