Beyond the Resume: How to Hire and Get Hired in Tech with Dave Hardwick
- 00:00 Introduction to the Podcast
- 01:04 Meet Dave Hardwick: Technical Recruiter
- 01:34 The Art of Recruiting: Insights and Challenges
- 05:54 Effective Interviewing and Scorecards
- 13:08 Crafting the Perfect Resume
- 20:45 The Unassuming Engineer's Journey
- 24:16 Common Resume Mistakes
- 25:13 Hiring for Startups: Values and Flexibility
- 25:34 The Realities of Startup Life
- 30:21 Resourcefulness and Leverage in Startups
- 31:29 Intentionality in Startups
- 32:53 Evaluating Engineering Managers and Directors
- 38:08 The Executive Mindset
- 40:08 Conclusion and Contact Information
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
- Dave Hardwick: https://www.linkedin.com/in/dave-hardwick-4596a0/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCtos #Podcast #Ctos #CtoPodcast #Technology #Engineering #SoftwareDevelopment #Entrepreneurship #Leadership #Management #EngineeringLeadership #TechnologyLeadership #EngineeringManagement #EngineeringProductivity #TeamVelocity #DevCulture #TeamCulture #EngineeringCulture #Agile #TechDebt #OperationalExcellence #EngineeringCultureMatters #EmpoweredTeams #DevProcess #StartupLeadership #EngineeringMaturity #ScalingEngineering #EngineeringOrgDesign #HyperGrowth #TechnicalRecruiting #HiringEngineers #EngineeringHiring #CTOHiring #RecruiterTips #ResumeAdvice #TechCareers #Scorecards #InterviewTips #StartupCulture #SoftSkillsMatter #TeamFit #HiringMistakes #StartupRecruiting #ExecutiveHiring
Guest
Brad: Most people think they know what they're looking for. They really do think at the beginning of search that they know what they're looking for.
And about 90% of the time they end up hiring someone who is not what they originally thought they were going to be hiring.
All right. Welcome, everybody,
to another episode of How Many CTOs Podcast.
I'm Brad Hefta-Gaub, but my co-host is...
Scott Poirier.
And today we have a very special guest with us, Dave Hardwick.
Dave and I have known each other as long as I've been a professional software developer.
predating you being a professional software developer.
That's true.
Technically, I was just an IT guy and a QA guy before I became a developer.
That's when we first met.
Just.
Yeah.
Hi.
All right. Hey,
introduce yourself,
Dave,
and maybe tell us a little bit about what brought you here to the How Many CTOs podcast.
Okay, I'm Dave Hardwick, and I'm a technical recruiter by profession these days.
I've had,
as Brad has noted, a long history in startups,
and before I was a technical recruiter, I did technical support and related sorts of things,
so long history there,
and we're here to talk about recruiting.
I saw one of their earlier episodes where they had another CTO on and they were talking about hiring practices and like that.
And it was really a timely thing because I just gotten off of a podcast with someone who was talking or another recruiter was talking about recruiting for technical talent and stuff. And it was it just really kind of lit my fire because.
There just felt like there are big blank spots in that discussion that made me realize that there's, you know, a lot of things that we do as recruiters that CTOs and hiring managers don't necessarily know that we do and also vice versa.
And, you know, there's there's a lot of very interesting things going on in recruiting right now, just as there is really are really interesting things going on in software.
and software engineering right now.
A lot of it's centered on AI,
but others of it is around process and how we work through things and stuff.
So they just seems like a timely time to talk about all those things.
Scott: So, welcome aboard.
And my question for you, kind of getting that first topic, is...
What is the way that you've seen that, you know, CTOs and recruiter, how does that marriage or partnership work best?
And I guess even to put a finer point on it, what do we, the CTOs, need to be doing that we're not doing?
Brad: It's a great question.
I'm always.
Whenever I get to work with this CTO,
I'm always really impressed with breadth and depth of their knowledge and how they,
the spaces they have to cover off to be successful.
It's not just technical, it's about the business.
Usually by the time people get to that role,
they've got a really good handle on, you know, all kinds of metrics,
how businesses make money, how they sell,
how teams sell.
things work with product and growth and all the things so it's really a uh usually it can be a really good conversation um most recruiters are not technical even if they are technical recruiter they they have never coded you know they know how to use technology and stuff and they're usually pretty smart people too but there's just gaps that exist
um and like i was doing a cert uh um in the winter uh this last year and um i was interviewing candidates for software engineering roles and stuff and the other recruiters i was working with one of them finally said hey can you um record one of your calls because we we're getting feedback that's unusual
in a positive way but we want to know what you're doing um to see kind of what we and what we would compare against kind of what we do and uh it was just you know i was asking we were looking at these senior engineers like staff level engineers and something i was asking them how they go about
um training junior engineers or how do you approach a code base and make it better over time what are your approaches around those sorts of things which are questions most recruiters don't typically ask because it's not in the job description right but it's a key part of that role and so I think I'm going a long way around the mulberry bush here Scott but I think that the
The thing is for me and what I what I wonder about is what are the things that you would like to be able to discuss with a recruiter ahead of a start.
to help them to be successful in finding those roles and stuff.
And like SDE2s probably aren't that hard, but as you come up the ladder for those more experienced roles and stuff,
like how do you as a recruiter know that that staff engineer is actually going to be positive add to the team?
It's interesting,
Dave, that I think what you're scratching at there.
I wonder how much of that is that as CTOs or as hiring managers for senior engineering roles,
is that a we're just bad at describing what we want or are we bad at even knowing what we want?
Oh, that's a great question.
So yeah,
it's a great question.
Maybe for both.
Yeah, I'm just like, okay, yeah,
so I don't think it's you don't know what you want.
Most, I think especially if we're senior position,
do you start with a notion of this is what we need to solve for?
And I think this is the type of person we should be looking at.
And you start going down the search and the recruiter starts bringing you people or you start doing some of their searching yourself and you find some people and then you go,
oh,
you have a really great interview or a really bad interview with somebody and you say, oh,
no,
we need to be going down this other path.
So there's always this information thing that happens as you go through a recruiting process.
And it informs kind of the next decisions you make about who to hire and stuff.
And so I think that's part of, I think that's part of what you're asking,
Scott,
to answer that question and or Brad.
You know, it's funny.
I was just, Dave, I just recently.
I feel like I had an experience like this where we're hiring an engineering manager role in the team that I'm on now,
and
Mm-hmm.
I thought I had like a really clear vision of what I wanted and interviewed a couple candidates and they checked a lot of the boxes that I had,
and then we moved them to the next level of having them talk to one of the engineers on the team,
and
Yep.
you know we're small enough that we don't have a structure of a process.
And
Mm-hmm.
one of the things that I realized as I was explaining to this engineer,
like,
hey, you're going to interview this candidate. This is what I'm looking for.
And they started asking me questions like,
well,
what about this? What about this? What about this?
And I realized,
like, of course, those were the things that I wanted.
And I had missed that in my interview loop.
and so that you know that developers like great okay we all agree that's what we want i'll make sure i i ask about that i
Right,
program that you know um
right,
but it was so it was so like i mean i've been doing this a long time and like it was pretty basic stuff it was basically about like technical acumen you know and
oh
you
wow,
okay.
know and i had and i had basically just blown right past that around like oh yeah you know like you know these people check check check they're you know great at team dynamics great at like
like you know kind of the small l leadership type stuff great at like process great at like they seem like they had all the cultural check boxes checked you know and like legit i just blew past like wait a second what is your expertise on this technology that we're using and it matters and
Yes, it does. It matters a lot.
Like, can you can
that's such
you
a like
code idiomatically
it's such a it's
in this language? Yeah.
Exactly. And even though as an engineering manager,
you're not necessarily expecting them to do coding,
but you definitely want them to be able to be good guides and mentors to the developers and help adjudicate the process.
But to me, that's just like an emblematic story of like,
of course I know this and yet I even missed it.
Yeah,
yeah.
And you kind of had a little tell there too where you're saying, well, we don't have much process in front of that.
You know, one of the things that, you know, as a recruiter, I really push people on is get your scorecard cards developed.
Show me this job description. What do you want them to do for the first year or accomplish?
And in an early stage,
that's hard to know, really,
you know, you like you said, you'd like there are these things that were in your mind,
all those things that were in your mind, they're totally terribly critical for success for that role.
But,
you know, there are additional pieces,
too,
that need to be addressed across the number of people who are going to be interviewing and stuff, especially hard in a smaller startup because.
Yeah, you want to be running light and nimble and fast and stuff, but those scorecards can really,
you know, if they're regimented and stuff, they'll really help you hit those things that you forget about.
Scott: Well, I'm going to add something to the scorecard piece because I found that to be a very effective tool in my career.
And in order to share this, I have to share a little context.
If the company I'm at now, we're not doing a ton of recruiting,
but in places I've worked at before,
we've hired very rapidly and we've always, I've always kind of said, hey, first of all, being an effective interviewer.
And bringing the right people onto this team is a really important skill for us.
And it's actually a very it's a transferable skill, meaning when you go to your next company,
being able to be someone who can identify and recruit talent is really valuable.
And so scorecards are a way also of training people for what to look for. And
Brad: Yeah.
Scott: it's also a way, at least in my experience, to demote.
democratize and scale a recruiting process i first started in the scorecards i mean a long time ago and we had a bunch of people reviewing resumes and everybody was doing it different and so then we were like okay we're going to make a we're going to make a scorecard here and we're just going to have a system like if you get seven or more of these checked off you get an interview you get to the first round of interviews and if you don't you don't and that's and there was one and one of the 10 there was 10 things on the list and you
you obviously get 10 one of the things of reviewers choice which was just like well there's something about this resume i'm going to give it a bonus point um and you know that was a way that we drove consistency and started to teach a lot of people like well this is how you look at a resume for this particular job
Brad: Right.
Scott: So I think the teaching part is big there for us as
Brad: I
Scott: well.
Brad: have an add to that.
There's another technical recruiter I think very highly of in Seattle,
and I was talking to him about how he goes through evaluating applicants,
right?
So going through the ATS and stuff.
And the one thing he does differently than I do.
or did i now i'm adopting this is for about every 100 resumes he parses through he will pick one out randomly and interview that person and
Scott: Mm-hmm.
Brad: the reason is because people writing resumes are crap through most of the time
um
Scott: Yeah.
Brad: and sometimes they have a really good resume it really does tell the story and you can really pick it out but there's a bunch of times where you look at it and you're like i have no idea
what why that person lied yeah okay
Scott: Yeah. Yeah.
Okay. So can we flip this around? We were talking about CTOs. Let's talk about candidates for a second. Let's imagine I'm a candidate or there's candidates listening.
How do you write a good resume?
I mean, not like, you know, textbook of have the objective of like,
what is it that you as a recruiter are trying to get out of the thing?
Brad: that's a good question um
There's a number of things.
First is, you know, job description match in terms of background.
That's a big piece.
So it's like, do they have the requisite number of years of experience?
Do they have the right degree?
um yeah have they done things that match up to the role so i look for those kinds of things um i do look a little bit towards their ability to convey information clearly uh and in uh you know because i think that's an important skill that transfers it'll also illustrate something probably code well um because language is kind of code um
So those are the principle things that I look for.
A lot of times for resumes or people who are applying and stuff,
there's just knockout factors that come to there really quickly. And usually when I'm doing evaluating resumes,
I look for the knockout stuff first, right? So one of the clients I had was a medical startup and they dealt with, you know, sensitive information,
sensitive data.
data and stuff and so people had to be in the united states now this is a remote role but anybody outside the united states was automatically kicked and they you know you just kind of look for those things that make for a rapid transition of making a good decision or not um but for the people who are who pass that through those no factors quickly and you're really evaluating for their skills and stuff um you know you
you do look for is this person ready for this role by their descriptions I don't
Scott: Yeah, that's
Brad: know if that answers your
Scott: interesting.
Brad: question
Scott: So very,
well,
it does. I mean, it tells me something which is it's actually a very almost black and white evaluation.
um like are the criteria met or not criteria not met um
Brad: Yep.
Scott: which is and which is interesting because then that comes back to something we were talking about a minute ago the importance of you know on my side of the table our side of the table being clear about what you want if i go out there and say find me someone who knows how to use technology x and not technology y
Brad: Right.
Right.
That's
And this OK. is actually an important point on LinkedIn profiles, too.
I just had a buddy of mine who was declined for a job because he had used sort of generic words to describe things he had done, as opposed to the technologies themselves.
And a lot of times when you're looking through applicants stuff, you want to see the technologies they've used in the jobs that they were in to see their progress and how they've evolved over time.
Yeah.
it's so interesting i always wonder about that you know it's it is funny like the alphabet soup of like you know c++ node you
Yep.
know java blah blah and i it's fair that like i definitely look at that and say like well we're you know this is our stack is is you know this and so does that person have experience in that
Um,
and then sometimes I it's it's it's so funny you say this, because, like, I don't even know how I mean,
like,
listing that it's like,
it would take like a page of alphabet soup to list all the things I've ever done,
you know?
Right, right, exactly.
And it's so then it's really like this,
I guess, and I, I guess I'll ask you as the recruiter, and this is kind of to Scott's question about the how does the applicant do a good job of this?
Do you recommend that applicants essentially make custom resumes for the job they're applying to,
where they specifically call out the things that they have in their experience that aren't being asked for,
so that the things that they are being asked for are at the above the fold, right?
That's a good question.
For software engineers,
so, you know, you guys probably have a broad audience, but for software engineers,
what I generally recommend is write a default resume that has everything.
And then when you apply for a given job, put the stuff in that makes sense for that, that role and stuff and then bring that out. Now, the one
Speaking of C++, I have a bias about software engineers and software engineers who have,
you know, coded in C++ I think are better.
A cut above.
And it's just that you have, there's just, there's a complexity there that I think makes a slightly better person,
better engineer.
Yeah, interesting.
But that's a bias So of mine.
what do you think?
What's that?
That's a bias of mine. I don't know that other recruiters would necessarily have that.
Scott: Well,
it's interesting you say that because I remember the checklist I was talking about a few minutes ago, I remember that one of the checkboxes on that checklist was.
did something technically difficult right
Brad: All right.
Scott: right
Brad: If you build something in C++, you did something technically difficult.
Scott: yeah that was that was a so you know one of the check boxes was you know familiar with our stack you know one of the check boxes was probably like has worked on a website before or something like that i remember them all but then there were then there were a handful of check boxes that were things like um
like that i don't remember what the other ones were but things like they kind of try to tell you more about the individual um but it's interesting that you talked about looking at the you know the concrete qualifications because maybe i maybe i'm doing it wrong because often i review a resume i sort of look at that
especially for more experienced engineers i tend to think well experienced engineers done a lot they can adapt probably to whatever stack we're using and
Brad: One would hope.
Scott: then i'm trying yeah um but that's valuable to know that they've used whatever stack we're using it's not always a deal breaker but then i'm trying to figure out from the resume and this is what i i often get frustrated with when i see the alphabet soup it's okay we've that's like saying
Brad: have a toolbox with a bunch of tools in it
That's
but what did you do with them right
right,
yeah,
and did you make a car because we don't make cars here we're like actually making medical devices so if i worked with a car company that'd be cool but like you know so it's to me i'm trying to like read i'm trying to understand both what is this person built with their tools and what is the what is the sort of arc
Scott: of their career like what's what's happening with
Brad: Right.
Scott: this person right
Brad: Oh,
I want to talk about this.
You've got it. This is a great topic.
So yes,
the alphabet soup matters.
And I think what you're kind of pointing towards is context is really important,
especially in terms of the things that you've accomplished.
And I had this really strange experience where there's a person who's recommended me to me after the big layoff at Microsoft.
soft after the the covid stuff happened and um and so i i took the call and and and i had him send me his resume and he was in the devices group which was just cut completely right and so i read through his resume and this guy was amazing i mean just holy cow and it started with um um
He got out of school, he had a master's degree, and he'd done a bunch of work in statistics.
And so for whatever reason, in Microsoft's infinite wisdom, they assigned him as a tester.
um and so he's working on all the stuff that's coming in from dr watson logs and those sorts of things and it was very manual at the time so i think the deed started like in 2008 or something like that and um so you know you would you'd look at the bug and you'd match it up in the bug database in the raid and then figure out kind of who the developer was and then assign it to him and stuff and he realized this we could i could automate this
And so he created this completely fully automated system, but it would take in debug reports,
match them up to the software that had been written and into the developer and then alert them via email to go fix the thing. Right.
And just that alone.
I was like, how much money did that guy save Microsoft?
And he was probably just like,
oh, yeah, it's obvious we should just do this thing,
right?
And he's a really unassuming guy.
And I just couldn't believe that like this guy was having a hard time getting recruited or hired anywhere because it's obvious this guy is like one of these engineers that's going to be a principal staff engineer someday.
You can see the arc.
And it was it was just and so I hooked him up with a well-known VP level kind of principal engineer person to help him along his career and stuff because it was just he needed he needed somebody to guide along.
and you're and the point behind the story is that this is somebody who had you could see in their story an arc that was compelling but
Yeah.
that was but you had to like read through the tea leaves of their resume to get that like you only got that when you really kind of talked to them is that is that kind of the point of the story
Well, it was in there, right?
And the point was that it's not just about.
you know the soup of the different kinds of technologies that are being used but rather you know he had enough of their story in there about what he had accomplished that you can see that you know time after time after time he's go he gets a new job and they put him in this really just hard work you know difficult to understand and he comes up with the answers it's just super consistent and so that
that kind of consistency of solving those hard problems was what really sold him on me um so that was that's kind of the thing that that I think is was really important in terms of telling the story I wish I could just show the resume because it just it it pops and but it does pop into like the way that most marketers think about popping right it's just like you you guys would have read it and said yeah I want this guy on my team he solves problems
Scott: Yes. So what's the other side of the coin? If I want candidate.
How do I just, you know, shoot myself in the foot with my resume?
Brad: Oh boy.
Lying is a bad idea.
You know, overstating kind of, you know, what you've done and stuff can be problematic.
um really it's and sometimes it's it's not obvious because like especially for startups and i'm curious about your you know how you guys think about this but um you know people hiring managers will say we should go hire some people from the following companies or whatever um and they'll tell a recruiter to go hunt those people down um and those are handy handy rubrics but the question i always come back with is so
What are your values? What are you hiring for?
And do the values from that company match to you or not?
And it's one of the things I think I was really curious about with respect to both of you guys is when you're spinning up a startup team,
startup engineering team,
what are the values that you sort of start off with?
And used as sort of filters of the people you're interviewing.
Well,
I mean, I I'll tell you now because I spent most of my time and start like,
you know, like the biggest the biggest company I ever worked for was when you and I worked together at Real Dave and and, you know, in the grand scheme of things that was still a relatively small company compared to like the big guys, you know, and.
Yeah, yeah.
You know, when you're on a team of, you know, tens of people,
you know, 10 or less or 50 or less,
you,
that requires a special,
that requires a sort of a willingness to be flexible,
that requires a willingness to.
To kind of like check your ego at the door, it requires a willingness to be incredibly scrappy, right?
Like, you know, it's, you know, there's this part I've seen this, I've seen this type of failure consistently where if.
You know, somebody might have years of great experience inside a, you know, whatever they call a fang these days, you know, but like if you were, you know, if you were at a company that had 10,000 employees and you led a scrappy team of 12 people in a 10,000 employee company,
that is not the same as being a member of a 12 person startup.
Like it's nowhere near the same.
It's no, no, no. It's entirely set different sets of skill sets.
Yeah.
Scott: Let me give you an example, and it's a personal one, so I'm not trying to toot my own horn, but it's a good one.
I was in a startup.
I was in a startup.
It has nothing to do with technical,
but it tells you the story of something about a startup.
So you're the 12-person team in the big company.
You still have a massive amount of infrastructure around you.
Okay, so I'm going to start up there's five engineers on this team and,
you know, we had a little lunch break room,
actually wasn't even a lunch room, there's nowhere sitting there, there's a place to counter to get coffee, coffee,
sink,
refrigerator thing.
And just everyone leaves their coffee mugs in the sink.
And I'm just, it's, it's really bugging me.
And so finally, I decide I can be bugged, you know, and someone puts a sign up, you know, classic sign,
your mother doesn't work here, you know, clean up your coffee mugs, nobody's cleaning up their coffee mugs.
Sidebar to the sidebar. I once worked at a place where someone,
someone's mother did work there.
I think, I think his name was Michael Johnson. And the sign said, unless your name is Michael Johnson,
your mother doesn't work here. So clean up your coffee mugs. Anyway,
so.
This is going on for a while and getting annoyed.
And finally, I just decided to say to myself,
well,
you know what?
I guess part of the CTO's job description is to clean the dishes in the sink.
So that's what I'll do now.
And for me, mostly I was doing that emotionally not to be aggravated every time I walked into the coffee room.
But to me, it's also a symbol of or a symbol symbolic of.
At a startup,
what you were saying about no ego,
you just have to be you have to actually enjoy doing whatever it takes to get the job done.
There
Brad: is Right, right,
Scott: no that's this other department that's going to do it. That's an HR problem or that's a facilities problem or that's a QA team problem.
It's all just all of our problems.
And so you have to you have to look for people who.
For that and you have people who enjoy that and who've demonstrated that before I think is tremendously valuable.
Brad: And I think that there can be a real culture shock for somebody that comes from a non-startup environment into a startup environment where,
you know, they don't, they just, it doesn't occur to them that like, yeah, actually we all have to.
You know fend for ourselves here.
We all have to be willing to do the thing,
you know, whatever that is,
whatever,
you know.
you know, file our own bug reports,
test,
test the other developers code,
you know,
Yeah.
well,
It's like you can't call it, you know, you give a shit or you care.
Either one of those two things, I think, is kind of what you're talking about.
and I also think that it's not necessarily just that if you're from a big company, you don't give a shit or you don't care.
I think it doesn't even occur to you that like, hey, if I don't report this bug.
that i just saw no one else is going to right because if you're used to sort of having this massive support structure around you it's like you see a bug you're like i'm sure somebody found that bug and reported it already and there's 10 000 of us
and certainly the janitor is going to come through at the end of the night and clean up the kitchen you know yeah all the things
Scott: So then there's another attribute I think you have to look for, which is resourcefulness.
And actually, I'll put another one with that, which is what I'll call a mindset towards leverage.
So resourcefulness,
you've got to figure out how to get more done with less,
which leads to a mindset with leverage, right? Leverage, leverage,
a lever is getting more done with less.
so you need people with a bias towards actions who are configured can be resourceful and get stuff done and do it in a way that actually gives the team leverage and allows the team to get more done and not do things in a way that slow the team down and that's just they're all just like crazy soft skills right they're not they don't show up in the alphabet soup right they
Brad: Right.
Scott: show
Brad: Definitely.
Scott: up and they show up and to go back to your example Dave they show up in the
automated the triage and bug tickets so
Brad: Right.
Scott: the PM didn't have to do it anymore and
Brad: Right.
Scott: nobody asked me to do that I just did it and it worked and everyone was happy I
Brad: Yep.
Scott: think those are all attributes attributes to look for for sure
Brad: You know, there's another part of that, Scott,
that I 100% agree with you about the sort of leverage.
But the other thing that's really important in a startup, and I would actually argue this is probably important in any like.
um,
you know, not yet pop, not yet profitable company.
Right.
Scott: Mm
Brad: And
Scott: -hmm.
Brad: that is like, we were burning daylight and we need to be really, really, really thoughtful about every little side quest that we have because we don't have the resources to
Scott: Mm
Brad: do side
Scott: -hmm.
Brad: quests, you know? And so this notion of not just doing things that get you leverage, but really picking your battles, right?
you
Mm
know don't don't over invest early right you know a really simple example of that might be like look if you're building a new feat like this is one of the things that agile tries to help teach us to do right like get your thing out there quickly so that you can get feedback on it so that you can know whether it's even worth continuing to invest in right like don't make the thing perfect
before you release it because you might make a perfect thing that nobody wants
Scott: Right, right.
Brad: right and that's like this that's not just leverage but that's a very much this mindset around i have to be really intentional about what i spend my time and energy on and what i even advocate that we as a team spend our time and energy on because we don't we're burning daylight here
Scott: So we've been talking about engineers a lot. Could we switch gears for a second and talk a little bit about engineering managers or engineering directors or VPs and what those resumes look like and how to identify those people?
Brad: Oh, that's a good question.
Scott: Let's leave out the VPs. Let's
Brad: Yeah.
Scott: just talk about engineering managers and engineering directors.
Brad: Okay.
That's, that's, that's, yeah.
Scott: I've come to you, Dave,
and I've said, hey,
we are going to hire a new director of blank.
Brad: Yep.
Scott: Machine learning,
data science,
software engineering,
data engineering,
whatever.
What do I need to tell you in order to have you be able to be really effective at that search?
Brad: Okay.
First off, what do you need them to do?
What's the mission?
Where is your team?
What are the challenges that this person is going to solve for you for your team?
Scott: Mm
Brad: How
Scott: -hmm, mm-hmm.
Brad: much do you want them to be technical and how much do you need them to be more corporate managerial? And what I'm really asking there in saying that is,
do you need them to do the budget and understand how that works,
that process works,
or do you just really need that person to do the technical stuff?
in a hard core
Scott: Mm
Brad: way right um and so it could be like you might be sitting it more towards like yeah i need this director but they kind of need to be a staff engineer too a little bit in terms of like coaching bringing up the engineering team kind of thing um so what are their soft skills how good are they at at um leading bringing their team along to be successful in total but also in terms of developing the careers for each of the engineers as they're going forward too
So I would pass
By the way, this sounds a lot like – yeah,
so Dave,
it sounds like one of the things you're basically saying is kind of what we said earlier and what we talked about with Ted about,
which is this notion of like know what you're looking for.
Yeah.
And as a recruiter, do you find that – how common is it that like –
Most, most people know what they're looking for or they do they or they not know what they're looking.
Scott: Most people think they know what they're looking for.
They really do think at the beginning of search that they know what they're looking for.
And about 90% of the time they end up hiring someone who is not what they originally thought they were going to be hiring.
And you just get informed in the marketplace. Part of it is, you know.
Brad: you know, there's the unknown unknowns, right?
Both in terms of what you think you know,
but also in terms of what is on the market because you didn't look for this particular role for the last five years or something like that, right?
Things have evolved.
And so that kind of comes into being.
And then it's not just you that's going through that, right? It's everybody who's part of that chain of the recruiting process.
So anybody who's interviewing is going to be having the same kinds of double clutching that you're going to probably have to.
And so all of those things have to be taken into account over time.
You know, I think it's interesting that you're, I love that you kind of pulled out the question of like.
Not just the technical skills,
not just the soft skills of leadership and management, but then the other parts about sort of like business acumen of of knowing how to do a budget,
you know, knowing knowing how to think about.
the implications of that new hire or you know or if you are doing a budget and the next thing you know there's a a reduction in force Right. or something like how do you really think about how do you really think about like the team that you have and how you live with less and how you choose how
Scott: Yep.
Brad: to live with less and that that's like
that's like so many pieces of not just not just the technical not just the the sort of like people management but also the where's the business going how do i think about where's the business going you know it's it's interesting certainly the higher the more senior the person is the more those demands are going to be
Yeah.
Appropriate.
Yeah.
Part of that too,
Brad,
is when you hire this person,
because a lot of times you'll take the director role,
for example, you might be hiring someone who's currently a manager and maybe they're at a bigger company and they've had some startup experience and so you think that's okay.
There's some coaching things you're going to be having to do with them for certain.
And do you feel comfortable with that in developing that part of that relationship?
with that person too that's sometimes somewhat overlooked in that level of a role oh
I had one of my mentors,
actually Martin Plain, you'll remember him, Dave, from the
yeah oh god Martin great
one of his things he kind of talked a lot about was this notion of like executive mindset.
And when
Scott: Yeah.
Brad: I first became a VP,
it was with him, and he talked about this notion of executive mindset being trying to balance and actually maximize,
not balance, but maximize your value to your customers,
value to your shareholders,
the value to your employees,
and the value to the community at large.
Right.
And that if you
That
that's
sounds very much like him.
Yeah.
Yeah.
And that that idea, it's so interesting because one of the things I noticed with there's there's a lot of times first time managers really,
you know, lean into the but I'm here to support my team.
Right.
And they're and they're and they think of themselves as maximizing that the employee vector.
And, and of course, there's all kinds of things that some anti patterns there that could get created like,
you know, ruinous empathy or something like that, where you're too nice to the team member that's actually struggling, and you're not really doing them any good, but you sort of think that you're the you're the you're the manager that everybody loves,
right?
Yeah,
yeah.
And instead thinking about like,
hey, look,
it doesn't like ultimately,
like if we're not delivering the software.
then
Scott: Mm
Brad: then
Scott: -hmm.
Brad: we're all at risk here if we're not meeting the needs of the shareholders the company right if we're not meeting the needs of the customer right like we're writing software that nobody wants right or we're writing software that constantly fails right it doesn't matter if we have we're enjoying ourselves and having a
time and love birthday parties we're not we don't we're not really achieving our goal as a manager and a leader it's
Right, right.
been a super fun conversation dave i'm so happy that you reached out to
Yeah,
us um
yeah.
to talk about this
Yeah, it was fun.
I agree.
And I certainly hope that you guys develop an audience with the recruiter, recruiter people.
because i think it'll help uh
Scott: We will.
So if I was a hiring manager who needed to hire a recruiter, where would I find you?
Brad: you'd find me on linkedin uh dave hardwick that's fun and then yeah i respond to dms and email messages and all this stuff so
We'll definitely include your profile in the show notes of this episode.
Thank you, Craig.
Yeah.
Awesome.
Yep.
All right.
Scott: Thank you, Dave.
Good
Brad: Yep.
Scott: talking
Brad: Thank you,
Scott: to guys. you.
Brad: Appreciate being here.
Cheers.
Scott: This episode of How Many CTOs Does It Take podcast was edited by Saffron Epgau. Our theme song was AI generated by Brad.
Brad: Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon,
or at our website at HowManyCTOsPod.com.
And remember to rate, review,
and subscribe on the podcast platform of your choice.