Wednesday, January 12, 2011

But We Can Get ‘em Cheap!

What’s wrong with that phrase?  A better question would be is there anything right with it…

“But we can get ‘em cheap” is the ultimate lie, especially in hiring.  Now, that’s not to say that you can’t get quality team members for “cheap”.  BUT, when you preface that with “but” it means that you don’t really want to hire that candidate.  It means that you are attempting to justify a bad hire with a claim of “cost savings”.

But the lie is that you’re not really saving money.

Let’s say that this “get ‘em cheap” candidate (A) would somehow accept an offer of $45K.  But you have doubts.  You wonder why somebody would take such a low salary with the experience that they claim on their resume, but you go ahead, extend the offer.  Surprisingly they except your low offer and so you get ready for your new employee.

In a parallel universe, you passed on candidate A because they weren’t good enough, even if you could “get ‘em cheap”.  So you keep looking, and maybe looking some more.  So you’re going to incur additional costs in the recruiting/hiring process.  But you’re confident that you’ll find a quality candidate if you keep looking.

So you keep looking.

And looking.

And looking.

And then you find candidate B.

But you’re pretty sure that they’re going to want at least $80K if not more.  And sure enough, after some negotiation, you settle on $90K.  Plus you definitely spent more time and money looking than you wanted to.  You’re pretty sure it’ll be worth it though.

Back in candidate A land, you start doing training.  You’re explaining a concept and you can tell your new hire isn’t quite getting it.  They are nodding away, but you’re pretty sure they just aren’t asking questions because they don’t want to appear incompetent.  You get the feeling that they are following the old motto “better to keep your mouth closed and be thought a fool than to open it and remove all doubt” might be your new hire’s strategy, but you can’t tell so you write it off as you just not being able to read them.  But you get the same feeling as you go through your other training sessions.  He also comes and asks some questions that are a little weird… and repetitive. 

But he was cheap right?  Well you’re now not only paying A’s salary but now wasting one of your productive developer’s time.  A’s not really getting much done, but you figure it’ll just take a little longer for him to ramp up.  But he keeps bugging your devs… and soon you realize that the new hire has been rotating around who he asks questions in order to make it less noticeable that he doesn’t know what he’s doing… so instead of repeating a question twice, it’s really that he’s asked it five times… and in code review it comes out that he still doesn’t get it.

So two months later you’ve tried and tried and things aren’t working out.  You have encouraged, warned and helped as much as you feel you can, but it’s just not working out.  Not only has A been minimally productive himself, he’s constantly needed help from others which means that your team hasn’t been as productive.  So you end up firing A and start looking again, until you find someone that you can “get cheap”…

Meanwhile in the parallel universe, candidate B is asking all the right questions… once.  You see the light turn on in his head as you explain your system architecture.  And the questions that he asks help you understand that maybe there are some improvements that could be made to your framework code to help ease development.  B is productive within two weeks and at the end of their second four week sprint has gotten as much done as most “ramped up” devs.

So which is the better deal?  Which really is cheaper?

“But we can get ‘em cheap” to me is the ultimate red flag.  It means that more than likely you’re getting a low quality candidate for a low salary but at a cost that is really higher than anybody should be willing to pay.

Are there ways to get good devs less expensively?  Sure!  Interns and new college hires can be a great way to get bright devs that can be trained easily relatively inexpensively.  But even that is not an endless pool as you still need more senior devs to mentor and train them.

There is another hidden cost/benefit that comes with a new hire, and this is probably one of the most costly: What do your other devs think when that new hire walks in the door for the first day?  Do they think “what a great addition to the team!” or “oh boy, I can’t believe I work here where they hire these people”.  Building a great team means that every hire counts. There is no room for “meh” team members on a great team.  Should they all be great in the same way? No! But they all should be great at something the team needs.

Even if your A turned out “okay” (half as productive as B, but decently productive) and you could hire two of them for the same salary as (or even less than) B, B would still be a better deal because 1) fixed per employee costs (like hardware, software, health insurance, benefits) and 2) your communication graph is smaller.  Your team will be tighter and more productive with a single solid performer that is able to raise the performance of the whole team than two blah performers.  Smart people want to work with smart people!

Just remember, if you hear “but we got ‘em cheap” when frustrated with a new hire, you’ll probably be hearing the same thing in 6 months when you’re training his replacement.


  1. I really wish I hadn't heard this exact phrase recently...

  2. There are cases when a candidate A type employee gets through the filters. When that happens, don't wait hoping that they'll eventually "get it". They won't. They won't ever get it. I'm sorry, but some people just aren't meant to be on your team. Cut your losses, fire the guy and find someone else (in that order because he/she will be a NEGATIVE producer). You can usually tell if you've got a candidate A type employee on your hands by simply talking to your best employees after a month or so of hire, they can "smell" their own.


Original design by andrastudio
Blogger port by Blogger Templates