Speaker 1: For those of you tuning in, this is a little
bit of a rough start, but it is the start
of the Adventures in DevOps podcast episode number whatever. I
don't even know what number were on anymore. But today's topic,
it's a little DevOps therapy session. Joining me in the
therapy room today, Warren Perrad to Born, Hey, you.
Speaker 2: Know, I h you say therapy as sort of a
joke there, but I frequently not as a joke, say
the tea and my executive title.
Speaker 3: It definitely stands for now.
Speaker 1: I mean it, it was kind of said with humor,
but like it's valid, especially today's topic, because I'm really
interested in getting perspective from you and Jillian welcome to show, Jillian,
how are you? I'm interested in getting feedback from y'all
on this topic because it's it's a valid thing, and
I don't think I'm the first person to ever face this,
So I think that's the beauty of having platforms like
this is to get perspective from people that you may
not otherwise be able to get perspective from.
Speaker 2: So I'm not a therapist, so if you have medical
needs there, I'm gonna have to definitely refer you to
licens passion.
Speaker 4: Right.
Speaker 1: I was kind of assuming here I was going to
walk out of here with a prescription for something sweet.
Are you telling me that that's not true?
Speaker 2: Well, I think there are a bunch of things that
are now legal in your state, So you know, maybe
just your look around your local city municipality and all
your problems could be solved by a short, little walk.
Speaker 1: Dude, that is an understatement for where I live. They
have totally embraced the new laws in this town.
Speaker 4: They haven't in New Hampshire. To drive a whole like,
you know, thirty minutes to Massachusetts before I can make
those dreams come true.
Speaker 1: That's horrible, Jillyan. A thirty minute drive.
Speaker 4: Yeah, something. It's not even more like, you know, one
of my sisters and my mom's lives, so it's not
like I'm not there all the time. Anyways, it's a struggle.
Speaker 1: When I lived in Arizona, they had an app called
weed Maps that was basically Uber for weed delivery, and
you would go and I never use it, but you
could go into the app place your order and then
some time later some drug dealers showed up at your
house and dropped off what you ordered.
Speaker 3: I've never, I've never used it, but I have.
Speaker 1: No I actually advised a guy who was creating a
competitor to that company. And yeah, anyway, on today today's topic,
before we just get banned from the show for conversations, Yeah,
so today's topic is is it possible to hire a
candidate who is too good for your team? And so
let me set the stage here a little bit. It's
funny because a few episodes back, I was talking about
how I think I'm just kind of tired of writing
infrastructure code and looking for something different. And now all
of a sudden, I'm the manager of the team here
and I'm backfilling the position that I vacated on the team,
and we're interviewing candidates. And one of the candidates we
interviewed is just an absolute rock star. And I hate
to put that term out, but he really is. He's
very passionate about DevOps. He understands the concepts and the principles,
and he knows how it relates to the business and
the value that his trade brings to making the company
a more successful company. And his skills are not to
put my exist team down, but they're like top notch skills,
and so one of the guys on my team who
did a technical interview with him, came back to me
and said, I'm concerned that this guy might be too
good for our team, because if we bring him on,
it's going to challenge everyone else on the team to
bring up their own skill set, because the average skill
set is going to be raised now. And I didn't
really think that's a horrible thing. It's always good to
have that kind of pressure, I think and it. But
the other point he made I thought was really valid.
Maybe this is the wrong company for that candidate, because
we are an early stage startup and a lot of
our processes aren't well defined, and sometimes we have to
go forward with things that aren't processes because it's more
important to ship the product and get feedback from our
customers than it is to build a long term, scalable
solution for it, you know, because in reality and startup world,
you may launch your product and it may fail miserably.
So you don't want to invest time and effort up
front building this super robust pipeline for something that's never
gonna see you know, long term, long term production use.
And so that was the part of his feedback that
really stood out to me, like, what if we brought
this guy on and he was starting to regret his
decision because we don't have enough opportunities to really take
full advantage of his skills. And so that's what I
wanted to talk about today. Is it possible to hire
someone who's too good for your team? And should you
do it anyway or should you pass on that candidate.
Speaker 4: I'm not sure that it's possible to hire somebody that's
too good, because I know, I mean, I know for
myself personally, I don't like to be the best person
doing the things that I'm doing. I always like working
with a variety of people, and other people are always
going to be like there's always going to be somebody
who knows more than I do. And maybe that's maybe
that's a personal preference that I just really enjoy working
on interdisciplinary teams. But I've worked on enough teams where
everybody thinks like that to make me think it. Maybe
it's a commonality among tech people that we all like
to be learning new things all the time, and that's
part of what brings us to tech. So I would
say from there, probably not. And I feel like this
is maybe a conversation that could be had with the team.
You could ask them like, hey, you know, how would
how would you feel about this? Like with your existing team.
Speaker 1: I mean, just go ask them, right, I see you
thinking heavily over Warren, What are your thoughts?
Speaker 2: Oh, there's so many things here, and I'm trying to
limit myself to whatever the most important aspects are. So
what I heard I actually the first thing that you
brought up of raising the sort of bar of expectation
of what people's levels are. I mean, I feel like
the most one of the biggest mistakes is incorrectly leveling someone.
So if you have the spot, if you can afford
hiring a principal engineer over a staff engineer, even though
you thought you only needed a staff engineer, it's fine
as long as they get that label and they get
the commiserate compensation for it, whatever that is in the environment.
If you're not doing that, then there's going to be
sort of a mismatch of expectations between what the individual
wants and what they could potentially get elsewhere. I think
one of the mistakes we tell ourselves is that, oh,
you know, uh, maybe in a couple of years they
would leave but I mean in the tech industry, they're
going to Whoever you're going to hire is likely going
to leave in a couple years anyway, So I often
like to throw that out. Also, I think one of
the worst things to hear, ever, is you're too qualified
for the role we want, And like, I don't think.
Speaker 3: That's great feedback for the candidate.
Speaker 2: I mean, especially in whatever market they're in or whatever
their circumstances is, they may be willing to take a
pay cut for some period of time because of their
own personal situation. And I think it would just like
if I was in that situation and that scenario, it
would just really suck for me to be told that
over and over again by lots of companies. Think literally,
I will like clean toilets, but no one will hire
me because they think I'm overqualified. It's like, please, like
I just I just want to do something else, and
I don't think that's a good reason. So I do
want to be careful about the bringing the level up
of the team. While it is good to push the
team members, you have to look at the culture of
the individual team members and what their values are, because
it can be a real struggle for them if they
don't feel like they're prepared or the kind of person
that wants to be pushed there, like you could be
driving a wedge within your team, and I have seen
that where there is a lot of pressure that people
may put on themselves because they now feel like they're
in a higher quality team in some way and they
have to meet that expectation, and maybe you start changing
your guidelines on what performance looks like because of that.
So I think being cognizant of those changes that will
happen because of that person is important as well, so
that for me starts to fall into fit right, you know,
what changes are they going to impact in the team.
If they're really too good, then of course they're good enough,
so that's never the problem. But you did say something
that I did catch on, which is that maybe you're
looking for a pioneer and they're more of a town planner,
which means they're not necessarily a fit for the type
of work that you want to do. They're actually not
qualified in that way because what they care about is
different for what you need. Now there is a question
of whether or not they want to work in that
mode or they are able to work in that mode.
But it's like, let's say you're hiring for a JavaScript
or Python, those are the languages you use, and someone
comes in with C Sharp and Java experience and they're like, Oh,
I'm super excited to you see.
Speaker 3: Sharp in Java.
Speaker 2: If you're going to go in the direction of changing
your language, that's fine, But if you expect them to change,
they have to sort of want to change. And so
I do wonder whether or not the criteria you have
in your job description is matches their expectations, or whether
or not there's an area to dive down there.
Speaker 3: So I think there's a.
Speaker 2: Couple of different angles that are all worth spending more
time thinking about.
Speaker 1: Yeah, that's a good point. Like our job description is
it's kind of your average, run of the mill infrastructure
DevOps type job description. It doesn't really elaborate a whole
lot on where they would fit into the team and
where they fit into the company. And I think that's
a really good distinction there.
Speaker 3: That makes it.
Speaker 1: Makes it a bit easier to say whether or not
this person is a good candidate because now you're not
talking Now you're not focusing on their devop skills, You're
focusing on their role within the team and within the company.
Speaker 2: Yeah, I mean skills there are five out of five,
and maybe there are six out of five for what
you're evaluating, great like, you know, pay a lot more
attention to those other areas, and maybe you want someone
Maybe the question you're asking yourself is would it be
better to have someone that's four out of five or
three out of five? But are aligned better with those
other requirements that we have for the culture or the
personal values or the area that they'll be working on,
or the processes that we have in place, and that
person may not be a match there. So I think
we're very quick, especially in the technology or engineering areas,
to believe that the skills level is the driving factor
for our performance and whether or not we should hire.
But often when I do interviews, we break it up
into a bunch of different areas that are like the
short term coding expertise, systems designed, whether or not it's
a cultural fit, and how they deal with certain individual
problems what we usually call a behavioral interview, and so
they can absolutely pass some of those and fail other ones,
and then it's about comparing along those each individual access,
but together across each of the candidates so.
Speaker 1: How do you decide or how like, when you're creating
a new role, how do you what your thought process
look like for determining what the non technical requirements are
for that role.
Speaker 2: So a lot of it comes from expectations of the
company and the culture that you have. For instance, it
could be super detail oriented, is really important for you,
I mean me personally at our company, myself, the executive
team we are, we really do care about getting things
done to say correctly in our regards. So high quality
is really really critical, especially with the product, the expectations
of our customers engaging with them, and so we look
to see people are going to achieve that. And often
that means for us generalists that have death in one
particular area that is important to round out the team.
So maybe we have someone that is deep in understanding
infrastructure in aws. Maybe we have someone that's deep in
specifically the security knowledge around on device management, credentials, et cetera.
Speaker 3: There's someone with quality. You know, there's a lot of different.
Speaker 2: Avenues that you go down here, people that want to
reach out to customers and handle support there. And so
it's very obvious for us when we're missing some area
and we want to find someone whose depth is in
that category, and that's how we sort of define the
job description, and then we play the game. We release
the same job description three or four times with different
titles because they may have had different titles at other companies.
Speaker 1: So you ab test your job descriptions and your job ads. Yeah,
for sure, Fresh Line, we're still going to go.
Speaker 4: Back to I think some of these issues could be
a conversation, maybe these ones with the candidate. I do
kind of agree that the you know, if we're going
to say there's a spectrum between startups and enterprise between
how like I suppose wild West the processes are, whether
they exist, how fluid they are, that kind of thing.
I would still say a lot of that is a
personality fit. Like it just seems like some personalities lend
themselves better to one type or the other. But I
have trouble believing that like a season tech professional, which
this person clearly is right, that he wouldn't know that
already and be aware of the fact that your company
is a startup and that maybe it's more on the
wild West side of the spectrum versus the enterprise E side,
and probably wouldn't have applied if that wasn't something that
he was interested in, right, Like, presumably this is somebody
with some choices in life.
Speaker 3: Yeah.
Speaker 1: Now, I think one thing I've already learned from this
conversation with you is I do need to go have
another conversation with this person and make sure that I've
clearly explained to the best of my ability the environment
that they're coming into and where we're doing well and
where we may not be at the level of some
of the things they've done in the past, just to
make sure that that doesn't come as a surprise to them,
and if they were to accept an offer, that they're
accepting it with all the knowledge that I can share.
Up friend, Yeah, I mean I.
Speaker 3: Feel like I want to disagree with Jillian.
Speaker 2: Uh yeah, yeah, Yeah, I mean I don't know much
angle to take care honestly. I mean, I think realistically,
when you turn down the candidate, you want to have
a better answer than you're too qualified for sure, So
how you get there is sort of up to you.
The journey you want to figure out. I think you
can definitely turn down a candidate because oh, they really
want the job, but we say we don't think it's
a fit for you and it's not a fit for
you because even though you don't know, or subconsciously consciously
you don't know, but subconsciously you need something different.
Speaker 3: You may be looking for a job.
Speaker 2: It may seem great to you, but looking at your
experience or what you actually care about, we know that
you're not going to be happy in I want.
Speaker 4: To find that response to patronizing. Like, I mean, I
get it, like it's your's you know, you're the hiring person.
You can hire or not based on whatever reasons you want.
But I personally would find that response to be very patronizing.
Speaker 3: I mean, the truth is a lot of people.
Speaker 4: It's the response. It's the response doesn't really.
Speaker 2: Matter well, I mean it's difficult to articulate in a
way which is clear and gives them comfort that they
aren't the right person for that role and to be
also happy about it. So yeah, I mean, there are
lots of things you can say, but I don't think
they're like saying that.
Speaker 3: You're there, you're overqualified. You know that that for me
is at the very low bar, uh, you know, end
of the spectrum.
Speaker 2: I definitely try to try to avoid saying that you're
not a fit for us here because what we need
don't doesn't match what you're currently giving us. You know,
these are the areas that we think that you're not
a match for. I would share that before the end
of the interview process, like give them the opportunity to
either justify or come around. And one way that I
do that is say, hey, like, we're happy to get
you on board if you think that our evaluation is
wrong here, but we're going to be looking at this
aspect and hoping that we're you know, we're wrong, that
you're correct, and we get through this and you know,
right now we're super hopeful, but we can take that step.
We can do the experiment, get you on board, and
then see how it plays out and maybe everything will
be fine. You know, it's a risk both ways. And
the thing I say a lot is we collectively are
really bad at interviewing people, like not just not my company,
but you know, like every company. And because we can't
really know someone in four to ten hours of an
interview process whether or not they're going to be effective
long term, actual evidence is going to tell us that.
So we're just trying to reduce the damage the wrong
decision will make on on our team on other individuals
on our company, and you don't, like you don't need
to necessarily do that upfront, you know, three three month
probation period, being explicit about that. Then you know, constant
feedback on what's going on so that they know what
where their areas are that they're missing, and like you said,
will like potentially self select out.
Speaker 1: Yeah. And one thing I agree with you completely on
is like the risk sponsor you're overqualified is not adequate.
Like this person they've invested time into this process too,
and so I owe them like a clear set of
reasons why we would think that they're not the right person.
And if I can't articulate that to them, then I
have to really I haven't done my job well.
Speaker 4: I think it's nice to you do that. By the way,
Like I've been applying for jobs lately, and a couple
of them were just like, now, which what with somebody else?
Which I mean, I guess it's something. It's a response anyways,
but it would be nice to get some more details.
Speaker 1: I think that's of the industry, Like the state of
the industry is, like you feel fortunate if you get
a rejection email. So many of them just you never
hear anything at all.
Speaker 2: Well, yeah, so I think that's definitely the first step.
I mean, what I hear a lot in some of
the communities I'm in is people are worried about potential
legal repercussion, or they have specific requirements or guidance from
their HR department or head of people to not explain
what the issues are because kendidate can I don't know, hypothetically, sue,
I mean, it doesn't really happen though, it's you know,
you're protecting yourself from something that is almost for sure
not the case. So I think just trying to actually
be a human being and be clear about what the
problem is and potentially give someone the opportunity to explain
themselves is what I definitely would recommend.
Speaker 1: Yeah, for sure, because a lot of this, a lot
of our current decision in this particular instance, is based
on some assumptions from previous conversations, and so it's worth
going back and saying, hey, here's what we're thinking and
then maybe learning something different, something that didn't come out
in the original set of interviews.
Speaker 2: Well, I mean i'd even take it further, like how
confident are you in your own interview process and in
your interviewers that are running that process to be gauging
the information you get back as qualified signals on those
different avenues. I mean, I know there are certain things
that I don't I'm not great at picking up on,
and so I need my other interviewers to help me
out there some things that maybe the question was phrased
in a way that the candidate wasn't expecting and or
wasn't prepared on a certain avenue, and then you maybe
double down on whatever they said there which doesn't match
their reality or how they actually think in that moment,
you know, misunderstanding that wasn't qualified. And I think those
are the sorts of things where you just end up
getting yourself into a bad situation where you're making a
decision based off of in perfect data both in volume
but also in your collection process. And so you know,
if you err on the side of well, no, actually,
we've been doing this for a very long time. We're
very comfortable in who the interviewers are and the collect
and the questions are asking and how they evaluate those.
Speaker 3: Then you know you can be comfortable and the answers
you get back.
Speaker 2: But if it's I've see it the biggest problem that
I usually see in the interviewing is that the interviewers
are usually just thrown together. They don't have a lot
of experience interviewing. They may be technical and we're talking
about culture behavioral interviews here, whether or not they're a
good fit long term for the company, they don't have
that experience, and sometimes the interviews come down to like
a panel interview where you have two plus people interviewing
the candidate, which is just like the.
Speaker 3: Numbers are not in the candidate's favor right.
Speaker 2: It can be a sort of viewed as the hostile environment,
and they're getting interrogated, and the questions don't often even
give you a good signal there of what's happening, and
so like all those things can contribute to getting a
confusing response, of which then you really just need to
keep diving down into further to qualify that.
Speaker 1: Yeah, No, that describes our situation completely when you think
about it, like in reality. Yeah, because I'm the new
manager to the team, and I've made a lot of
changes to the team since I've taken over, So there's
you know, there's some uncertainty across the team there, and
then the we don't interview many people period at this company,
so we don't really have a strong historical past or
historical record of how we've done and interviews in the past.
And then let's add one more plot twist to it.
We're an early stage startup that's still trying to find
out what we do for a living. So there's it's,
you know, shifting sands.
Speaker 3: For sure. It's never too late to try to figure
out what you want to do with your life.
Speaker 1: Right I'm fifty four and still trying to answer that question.
I'm feeling some pressure, though, I'm not gonna lie.
Speaker 4: I think one of these days we should have a
show on making the switch from a purely technical role
to not Is that something I keep hearing about, maybe
because it's my own personal struggle, But anyways, next Jef,
next shop.
Speaker 2: No, I mean, I think that's an interesting topic. I
actually have found that now for the current state of
the tech economy, it's going to be less of a
question because companies are cutting out what they call middle
management team leads and are having and going to a
quote unquote flat organization, which is just a made up nonsense,
and they're less concerned about having canonical responsibilities that match
what we would have historically called career people management.
Speaker 4: That's the pendulum that's going to swing back, though maybe
not like fully to the extent that it was maybe
let's say, like before COVID. Maybe it was too bloaded
before COVID.
Speaker 3: But I just.
Speaker 4: I don't know. I've worked with too many engineering teams.
I feel like there needs to be like some level
of adult supervision there.
Speaker 1: So the approach I've been taking with my team and
to change changes I've made is putting more responsible and
authority on the senior engineers, saying I don't need to
be in a meeting as a manager. I don't need
to be in a meeting unless there's a problem. You
own this product, go meet with the team that builds
it and figure out how to get it done, and
make the decisions that you know how to make. You've
been doing this a long time. You know what to do,
you know what not to do, and just go do it,
and if you're wrong, we'll fix it. Nobody's going to die.
Speaker 2: Yeah, I mean, I really like the mentality of turning
the ship around and pushing the delegating down to where
the decision should be, which is the information that the
people have, so how you select who should be making
a decision along with them having the competence the capability
to actually do that. And I think those two are
the pillars that David Marque actually talks about there. And
you know, not everyone is at that point, but trying
to get them, like as a leader, trying to get
them to that point is like the stepping stone to
be thought of. And a lot of people are too
short term focused. So like in the perspective of we
need to hire someone, consumably there's some short term, some midterm,
and some long term problems that you're looking out for
that you think someone needs to come in and support
that because your current team can't handle it in some way.
Not this like made up we need to scale, but
realistically we are going to fail in this particular way,
and that's where we need someone to save us. And
obviously the short term mindset not the best one. But
we can hire someone for three to six months to
handle the short term problem. How are we going to
hire someone, you know, six months, three year, a couple
of years to handle the medium term problem. So I
mean you keep swapping up people, for sure, but I
think that's sort of how I personally engage interviews when
creating a job description and trying to find that person.
So maybe the person you've got, like you said, maybe
they're the perfect person six six years down the road,
or you know what they're going to set up for
six years down the road, maybe they're not really the
startup person. I know when people start companies started moving
to the room situation. One of the problems that we
had initially is a large pool of our potential candidates
had never worked in a remote environment, and we had
been remote even before the pandemic, And realistically a big
problem is a lot of people are like, oh, remote,
that sounds great, and I'm like, okay, but you know,
it's different working in a starufference. It's different in some
meaningful way. And people say, oh, yeah, whatever, startup, that's fine.
You know, maybe it's less certainty. I'm like, okay, but
you don't really understand what less certainty means in a
day to day environment, Like you may subconsciously understand that, oh.
Speaker 3: The job may not be here in two years, but
that actually means.
Speaker 2: How you work on things is fundamentally different than working
in a different stage of a company with different particular problems.
Speaker 1: Yeah, the example I used for that is, like, let's
define uncertainty. Uncertainty means you get a call in the
middle of the day from your wife who wasn't able
to buy grocery store groceries at the store and had
to put them all back because your paycheck bounced because
your employer was out of money and didn't feel that
it was needed to be shared across everyone who thought
they just got paid. That's that's the level of uncertainty
at startups, just for odd, random examples out of nowhere.
Speaker 4: Yeah, Alex, your groceries are not other people's top priorities.
They are your top priority, though, so kind to balance
those things. I mean it before made an interesting point
earlier that, like, you know, you can't hire people short term.
Speaker 3: I know.
Speaker 4: I've worked for a few companies that almost everybody starts
off as a contractor, and that's kind of their way
of making sure that you're like a cultural fit, and
then you know, if they like you, they hire you
full time. I've also been places where contracts were yearly
and so they just never they never fired like anybody,
like people did like truly bananas, things right just off
the wall. Bizarro behavior. Nobody ever got fired because of
the year the contract would expire and then occument and
then they just wouldn't rehire you. So there's like, there's
plenty of ways around that, although of course that's not
what you want to happen, right. You want to hire
the right fit and they're there for a couple of
years with the duration of the project or that kind
of thing.
Speaker 2: I mean, you brought up a really interesting sort of
parallel here with the how does the employment contract look like? Uh,
how what is the payment schedule?
Speaker 1: Like?
Speaker 2: Uh, what is the legal aspect behind the engagement? And
unfortunately these seem like they're more coupled than I would
like just from a you know, individual mindset perspective. If
I'm on a contract, oh that will likely end. Companies
should not just not renew the contract. There are so
many contractors that I know that get to the end
of their you know, six month or year contract, like
I have no idea if I'm going to have a
job in two months, like, and I'm not going to
find out until the year rolls over, and then I'm
going to be told whether or not I have any
Like that's just a terrible situation to be in, and
I think that way.
Speaker 4: There's people who don't feel that way.
Speaker 2: Like really well, I mean, for instance, when we hire
people out of say some Eastern European countries, it's more
common for us to use a employment contract that is
between businesses, just because of how local employment laws work
and how they're actually better for everyone for the individually
set up as a company. So we use individual like
corporate contracts there, but we don't treat them as contractors.
So like, how the legal setup is is completely different
than the expectations on how they communicate or engage with
the team, how the culture works, and like I think
that there is a tendency to couple those together, but
they absolutely don't need to be that way. So yeah,
I mean, if you're scared because you know every contract
you have is going to potentially end, like I feel
like your employer can be doing a much better job
letting you know way ahead of time. Like I would say,
if you're on a contract and you're in one of
these situations and you don't have the personal expectation that
at the end of the contract going to be over,
I'd add into the contract like will automatically renew less
in the three months leading up to, like to the
end of the contract.
Speaker 3: It is is explicitly you know, canceled.
Speaker 2: And then you sort of bake in a little bit
of safety like mental safety psychology there for yourself so
that you don't end up in a situation where you're
basically in limbo as far as what your future job.
Speaker 4: Is going to be.
Speaker 1: Yeah, and that's great advice for anyone who does contract work.
Add that clause in there, because that's it's a recurring
thing that I've heard over the years. You know, hey,
my contract's going to expire, and no one's really saying
anything or answering questions. So your role, like Gillian said,
your responsibility is to put groceries on the table. That's
not your employer or contract partner's responsibility. So you're just
looking out for yourself when you add that clause to
your contract.
Speaker 4: Yeah. So, I mean I've been doing the contracting thing
pretty much full time. I mean, presumably I have an escort,
but like basically I just have like a bunch of
like little jobs that are that are that are all
very flexible, right, and I have added those kind of
things to contracts. It depends on, like the company that
I'm working with, how much of the contract is sort
of boiler plate that I'm not going to like. I
don't know. I'm not going to go hire a lawyer
just just to deal with this stuff, right Like, it's
it's just me and I don't even really work full
time most of the time. But I'm also concerned by
how I would ever enforce something like that.
Speaker 3: Yeah, I can never come up.
Speaker 4: I just go get another contract.
Speaker 2: I mean those of us that are in a fortunate
position that you know, that's what we can do in
those circumstances. Often the best advice I would give here
is make it so that you don't like If you're
in that situation, it's not the end of the world.
So I don't know if that means charging more, that
means start charging at the beginning of the cycle, using
a retainer based So when I do consulting, I usually
do a retainer at the beginning of the month, which
I don't care what happens at the end of the month.
Speaker 3: It's I've already been.
Speaker 2: Paid for whatever happens there, and I know whether or
not to start working or whatnot. And then maybe increase
that even more, uh, based off to let yourself have
the freedom to deal with those anomalous events where you're
not you don't have the transparency with that particular client.
So yeah, for sure, like you're not gonna get into
a legal battle at all there, Like you're not going
to go through that process in most cases.
Speaker 3: So I'm totally with you.
Speaker 1: I think that's a really good point. A little bit
changing topics here, but totally worth doing. Because of the
number of people in our industry who do contract work,
and that comes down to setting the proper hourly rate
for your services. A lot of people jump to the conclusion, oh,
I want to make one hundred thousand dollars a year,
so I'm going to charge fifty bucks an hour, right,
And that's true. That half works, but that doesn't really
take into account everything that you are doing as a contractor.
Because as a contractor, for every hour that you spend
working on the problem you are hired to solve, you're
going to spend another hour doing the financial aspects, the accounting,
the book keeping, the taxes and all that kind of stuff.
And then there's another hour spent on top of that
spent marketing looking for your next client. So for every
hour that you work, there's two unpaid hours in there
of just running your own business, because that's what you
are as a contractor. And so when you set your
hourly rate, you want to get paid for that time too.
So your hourly rate needs to reflect all the work
that is not hands on the keyboard, building Docker files
or writing terraform infrastructure.
Speaker 4: Yeah, for sure, you really don't bill as many hours
as maybe you think you will, like, Oh, it's going
to be great, I'm going to bill all these hours
and make all this money, and then you realize everything
else you have to do to actually keep the ball rolling.
So if you're starting off whatever you think your hourly
rate should be, probably just double it. I'm just just
gonna go with just double it right away.
Speaker 3: Yeah already. Then.
Speaker 4: Yeah, do you feel like you have a good plan
of attack? Well, what are you gonna what are you
gonna do? When you Oh?
Speaker 1: Absolutely not. I'd be scared shitless if I felt like
I had a good plan.
Speaker 4: Like, surely there's something I'm missing.
Speaker 3: No, I do.
Speaker 1: I think A couple of key takeaways I got from
here is I need to really take a step back
and think about what role this person has in my
team and define that so that everyone on my team
who's interviewing them and the candidate themselves has a clear
set of expectations of what this job entails outside of
writing terrorform code.
Speaker 4: And then.
Speaker 1: Have another put another step in the process, or maybe
just do this when one off or whatever, But I
need to have another conversation with this candidate and really
let them know what we're thinking, why we have those concerns,
and give them an opportunity to address those specifically.
Speaker 2: You also have an opportunity for a sort of risk
evaluation for your business, like how bad would it be
if you hired the candidate even knowing Like let's assume
all those things were true regarding the candidate and the
potential problems, Like what is the actual impact for the business,
Like if you how bad would it be like in
three months, six months, I'll till you had to fire them, Like,
you know, is it likely that they would cause the
startup to actually fold?
Speaker 3: You know in that way?
Speaker 2: Because like I feel like we don't do a great
job sort of evaluating what the risk is when we talk,
you know, with anything honestly interviews, buying SaaS, software.
Speaker 3: Pulling in libraries, et cetera. You know, we don't really
do a great job doing that.
Speaker 2: We usually have a lot of fear up front about
making the right decision, but then we don't really think
about our recourse as much if it is the wrong one.
Speaker 1: That's a really good point. That's one that we don't
talk about near often enough, like the risk of it.
And I'm glad to hear you say like SaaS evaluation,
because that's a pet peeve of mine and I feel
like I'm the only person who has that pet peeve,
you know, Like you use a SaaS provider and you
send them a bunch of your data and then they
get a security breach and now all of your customer's
data is out in the wild because of something they did.
And like, the absolute best case scenario you can hope
for in that situation is that you get an at
mentioned in the tweet from their CTO when they say
how sorry there are, and what steps they're going to
do to make sure it ever ever, ever happens again. Like,
that's the best case scenario.
Speaker 2: So we put eslays in our contracts to handle repayment
to customers if we there is like a serious problem.
Usually it's around up time specifically. But you know, honestly,
I see a lot of people on the opposite side
of the spectrum that are so heavily evaluating which SaaS
provider to go with. They spend months and months trying
to pick one, And honestly, the answer is like, forget,
You're never gonna know what the impact is going to
be until after it happens. You're not going to be
able to predict that. Forget it, Like, just you're better
off just those two months that you wasted like tens
of thousands of dollars doing that evaluation. It didn't doesn't
amend to anything. Just pick one, go forward, see what happens,
and then pivot if you need to, because you're not
gonna be able to figure out what the risk is.
There are companies out there with tens of thousands, hundreds
of thousands of engineers who have all the certifications in
the world trying to prove that they're secure, and they're
the ones that are the one are posting oops, we
had another security breach yet again. So I mean, you're
not going to be able to evaluate that upfront, do you?
Speaker 1: This is way off tangent, but I'm curious, do you
accept negotiations in contracts regarding your slas, Like you say, hey,
we promised this with our SLA. This is our commitment
to you. If a potential customer comes back and says,
that's all cool, but we want this SLA instead, do
you entertain those negotiations.
Speaker 2: The answer is no, but for two reasons. One, our
default SLA is like incredibly high. We are four and
a half nine's by default is what we put everywhere.
There's no like super enterprise plan where we promise on
even higher SLA, so people can't really request that, nor
would they need to. And the truth is that just
promising a higher SLA like you can't even really deliver
on that. The SLA is a made up number.
Speaker 3: You know.
Speaker 2: We can use our slis and are whatever our internal
objectives are to decide how much we want to be up.
But realistically you'd have to have a fundamentally different product
in order to reach the next level of SLA. It
doesn't really make sense to promise some customers a low
SLA and other customers a high SLA. The ones who
want to high SLA are the ones that are paying
you lots of money. So you're gonna end up paying
out a lot of money if you have a problem,
even a little problem. So the ones that don't pay
you anything don't really care what your ESLA is. You're
not gonna end up paying them out a lot anyway,
even if you gave them a higher SLA. So it
doesn't really make any sense for us to have that
disparity and make some companies who are building critical products
but don't pay us a lot of money feel like
they're second class customers for us.
Speaker 3: So we don't offer different scales like that.
Speaker 2: I mean, if someone wanted us to have a higher SLA,
I do the never split the difference perspective. This increases
the risk for us, so you will pay us more
money upfront for that SLA.
Speaker 1: For sure.
Speaker 2: I have no problem increasing that SOLE with a higher
upfront cost, and we for sure will make those trade offs.
Speaker 3: Usually it's like, do you actually really need that? No, No,
you don't.
Speaker 2: I mean your own software isn't even that high realistically,
so I don't know why you expect some vendor to
be even higher than that.
Speaker 1: Dude, I love your insights. I love throwing questions like
that at you, because like your like the ven diagram
thing of your business skills and your technical skills is
pretty cool.
Speaker 3: I'm bad at both, That's what I'm hearing.
Speaker 1: But maybe you're bad at both, but the overlap is great.
Speaker 3: You know.
Speaker 2: It's interesting because like I was a very technical person.
I studied engineering, and then the jobs that I got
put into were very customer focused technical support, not so
hard software development or working with the people on the
shop floor and manufacturing and building software for them. So
I was always uniquely in a situation where or I
had to fully understand what my customers actually cared about,
my users actually cared about, and less about the technology.
And I told myself that lie that every engineer that
didn't really have a job tells themselves, which is I
just want difficult technical problems to solve, Like, no, you don't.
What you want is problems that you think are technically difficult,
but you feel like you were able to solve them
pretty easily and then patch yourself on the back. I
mean that's what everyone wants, like perceive that it's difficult,
but then able to actually solve it, and after a
while you're like, I actually don't want complex, difficult problems
to solve, because if I have those, that means something
is fundamentally broken with what we're.
Speaker 1: Doing for sure. I think that was one of the
big insights that helped me on my career, is that
no one gives a shit about the terraform code I write.
What they care about is that the terraform code I
write allows them to ten x their customer base without
increasing operating costs.
Speaker 4: That's why I like working with scientists, because like, it's
a nice public experience and that I know, Oh, I
know for a fact, if they could get rid of
me and do this and like excel on their laptops,
they would, they absolutely would. They would push me out
the door, like and if I'm really lucky, I might
get like a fruit basket or something. As I'm being
pushed out. I would be on so fast that it
would just be remarkable. So it's good. It's good to
always know that that, if you know, if people could
solve the problems without technology, they would nobody cares about
your elegantly abstracted uh Python classes or something. Good.
Speaker 3: Good to know.
Speaker 1: All right, should we do some picks?
Speaker 3: Yeah?
Speaker 1: Sure, all right, what'd you bring?
Speaker 3: Jillian?
Speaker 4: I forgot again. I had one. I was thinking about
one during the week and I was like, this is
going to be a great, a great pick for the show.
Speaker 3: One.
Speaker 4: I have a futon mattress that I bought from Amazon,
and that thing is great for yard naps. So I've
just been like throwing my tark outside and then putting
the Futon matt and then I just like lay around
on that thing all day. And it's great because it
is unseasonably warm for November in New Hampshire and it's
just it's like the best thing ever. I was dog
sitting one day and the dog really appreciated it too.
It was lots of fun, had friends over, They've taken
yard naps. It's been a good time.
Speaker 1: Amazon Futon mattress for yard naps.
Speaker 3: Yeah, all right, that's it.
Speaker 4: That's the pick. It was great I ever spent.
Speaker 1: We have snow on the ground, so I'm not gonna
exercise that pick right now, but I'll check back the
spring after things start.
Speaker 4: Warming up, and you know, springtime, you'll be there.
Speaker 1: All right, Warren, what'd you bring?
Speaker 2: I feel like you can put the tarp on top
of the snow if it's not melting.
Speaker 1: I was thinking the temperature is probably more the limiting
factor than the snow, to be honest.
Speaker 4: Well, if you have the futon, then you don't get cold,
so presumably I bought it.
Speaker 1: It's cold everywhere out there, it's cold everywhere, not just
on the ground.
Speaker 4: Okay, that's true, but that's what really makes you cold
if you go camping, is like when you're laying on
the ground that it's the ground that's cold. So if
you have the mattress, then you have like a buffer
between you and the cold.
Speaker 1: Yeah. I think I'm not quite climatized from Arizona for
that yet.
Speaker 4: Okay, you still need some time, huh yeah.
Speaker 3: Oh oh.
Speaker 4: Then the other pick is that I got a heated
mattress pad. And this thing is great, This is like
quite this might be better than the than the yard
mattress futon thing, it's very nice.
Speaker 2: I feel like the secret pick is both of those together.
First the tarp, then the mattress, then the heated mattress pad,
then then the futon, and then your goal.
Speaker 4: Then yeah, that's it. That's like the perfect combination. That's
what I need.
Speaker 1: So you can bundle it and create an Amazon affiliate
link and then just post that in the show notes,
I could.
Speaker 4: You know, forget all these technical skills that I presumably have.
This could be the money making scheme of my.
Speaker 1: Dreams, right, all right, what'd you bring? Yeah?
Speaker 2: So, first statistic, which is just really shocking for me,
some research that had been completed recently shows us that
about zero point five percent of our brain matter is
now composed completely of plastics. Zero point five percent. I
mean that's that's like a ridiculously high number.
Speaker 3: Like this is just so high.
Speaker 2: I can't believe I think the study the scientist was saying,
I even can't believe these words are coming out of
my mouth right now, Like it's so shocking to have.
Speaker 3: Read like what we actually discovered here that is just
so high.
Speaker 2: So like I don't have any I don't have any
real solutions for that other than, like, you know, stop
using plastic in every way, like everything you buy, just
like cancel. But my pick is going to be something
that I started only recently a couple of years ago,
which is to help combat the forever chemicals that we
may consume from the baking papers and pans and whatever
plastics are in the air that get into our lungs
and end up in our and our brain, and that's
a blood donation for sure. Like the medieval times they
had something, you know, blood letting. You'd go and get yourself,
drop some quarts of blood on the floor, some leaders
and uh you know anything that's in there that needs
to get out for sure. Well though, you know, you
can donate your blood to a hospital or clinic that
absolutely needs it, uh, in case of some sort of emergency.
Speaker 3: So it's a double win.
Speaker 2: You get to remove some forever chemicals from your body
that are likely going to be responsible for some part
of your eventual death, and and.
Speaker 3: Also help the community out at the same time. Right on,
I like that?
Speaker 4: Is that like a thing that works though, because your
body is making new cells and new tissue and new
everything all the time. Like the meat sack that is
you is not the meat sack that was you ten
years ago, right, So does it actually get rid of
the plastics or the forever chemicals if you're they're in
your bloodstream like releasing blood but really blood?
Speaker 3: Sure?
Speaker 2: Well, some of us, about fifty percent of the population,
have a built in genetic strategy for constantly getting rid
of blood, which includes whatever permanent chemicals.
Speaker 3: May be built up there.
Speaker 2: But for sure, anything in your bloodstream that is there
is going to get removed. I mean, not a huge amount,
like one liter out of a small number, a small
amount that actually exists in your body. But it's not
like your bone marrow is producing plastic based blood cells there.
So you are removing a volume of liquid which does
contain in it forever chemicals that have no other way
out of your body because your body isn't filtering them out.
Speaker 3: Yeah.
Speaker 1: I gave blood the other day and there was like
a Hershey's wrapper that came out.
Speaker 4: That's probably a lot of time blood streams as well.
It's like just chocolate and candy and jump the shock amount.
Speaker 1: All right, So my pick, I'm picking a book by
Timothy Leary and it's The Psychedelic Experience, a manual based
on the Tibetan Book of the Dead, and it's been
really entertaining. I'm only about halfway through it, but it's
been super entertaining. The Tibetan Book of the Dead is
a book I think about three thousand years old that
was used even though it's called the Tibetan Book of
the Dead. It's a book about releasing the ego and
learning how to live. But then Timothy Leary, who was
famous in the sixties for the being one of the
prominent figures of the psychedelic movement, he read that book
and then associated a lot of the things described in
that book with psychedelic trips, and so then he wrote
this book that ties the different stages of a psychedelic
trip to the different different stages that are described in
the Tibetan Book of the Dead. And so I just
find it really fascinating. It was a cool read.
Speaker 4: Did you read the book by the guy that went
to South America and like had lots of trips for
DNA and was like all the psychedelic people knew about
DNA long before you know, Rosslyn Franklin or the people
who went along and imaged it. No is that I
don't I don't remember the title now, but I'll try
to get it for you because it's it's a very
it is a very entertaining read. It's a good time
right on cool in Las Vegas, but with DNA it's
great a right on.
Speaker 1: All right, that's an episode. Thank you both for your input,
thank you for joining me on this show, and thank
you listeners for listening. Be sure and let us know
on all the different socials if you have comments, thoughts, input,
topic ideas, or want to be a guest. And with
all of that out of the way, i'll see y'all
next week.