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.
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.
It definitely stands for now.
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.
So I'm not a therapist, so if you have medical needs there, I'm gonna have to definitely refer you to licens passion.
Right.
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?
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.
Dude, that is an understatement for where I live. They have totally embraced the new laws in this town.
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.
That's horrible, Jillyan. A thirty minute drive.
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.
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.
I've never, I've never used it, but I have.
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.
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.
I mean, just go ask them, right, I see you thinking heavily over Warren, What are your thoughts?
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.
That's great feedback for the candidate.
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.
Sharp in Java.
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.
So I think there's a.
Couple of different angles that are all worth spending more time thinking about.
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.
That makes it.
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.
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.
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.
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.
There's someone with quality. You know, there's a lot of different.
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.
So you ab test your job descriptions and your job ads. Yeah, for sure, Fresh Line, we're still going to go.
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.
Yeah.
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.
Feel like I want to disagree with Jillian.
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.
You may be looking for a job.
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.
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.
I mean, the truth is a lot of people.
It's the response. It's the response doesn't really.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Then you know you can be comfortable and the answers you get back.
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.
Numbers are not in the candidate's favor right.
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.
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.
For sure. It's never too late to try to figure out what you want to do with your life.
Right I'm fifty four and still trying to answer that question. I'm feeling some pressure, though, I'm not gonna lie.
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.
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.
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.
But I just.
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.
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.
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.
The job may not be here in two years, but that actually means.
How you work on things is fundamentally different than working in a different stage of a company with different particular problems.
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.
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.
I know.
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.
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?
Like?
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.
There's people who don't feel that way.
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.
It is is explicitly you know, canceled.
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.
Is going to be.
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.
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.
Yeah, I can never come up.
I just go get another contract.
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.
It's I've already been.
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.
So I'm totally with you.
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.
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.
Yeah already. Then.
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?
Absolutely not. I'd be scared shitless if I felt like I had a good plan.
Like, surely there's something I'm missing.
No, I do.
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.
And then.
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.
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?
You know in that way?
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.
Pulling in libraries, et cetera. You know, we don't really do a great job doing that.
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.
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.
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?
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.
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.
You know.
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.
So we don't offer different scales like that.
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.
For sure.
I have no problem increasing that SOLE with a higher upfront cost, and we for sure will make those trade offs.
Usually it's like, do you actually really need that? No, No, you don't.
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.
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.
I'm bad at both, That's what I'm hearing.
But maybe you're bad at both, but the overlap is great.
You know.
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.
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.
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.
Good to know.
All right, should we do some picks?
Yeah?
Sure, all right, what'd you bring?
Jillian?
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.
One.
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.
Amazon Futon mattress for yard naps.
Yeah, all right, that's it.
That's the pick. It was great I ever spent.
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.
Warming up, and you know, springtime, you'll be there.
All right, Warren, what'd you bring?
I feel like you can put the tarp on top of the snow if it's not melting.
I was thinking the temperature is probably more the limiting factor than the snow, to be honest.
Well, if you have the futon, then you don't get cold, so presumably I bought it.
It's cold everywhere out there, it's cold everywhere, not just on the ground.
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.
Yeah. I think I'm not quite climatized from Arizona for that yet.
Okay, you still need some time, huh yeah.
Oh oh.
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.
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.
Then yeah, that's it. That's like the perfect combination. That's what I need.
So you can bundle it and create an Amazon affiliate link and then just post that in the show notes, I could.
You know, forget all these technical skills that I presumably have. This could be the money making scheme of my.
Dreams, right, all right, what'd you bring? Yeah?
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.
Like this is just so high.
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.
Read like what we actually discovered here that is just so high.
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.
So it's a double win.
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.
Also help the community out at the same time. Right on, I like that?
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?
Sure?
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.
May be built up there.
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.
Yeah.
I gave blood the other day and there was like a Hershey's wrapper that came out.
That's probably a lot of time blood streams as well. It's like just chocolate and candy and jump the shock amount.
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.
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.
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.