Minesweeper and bad hires

Hiring programmers is hard, expensive, and takes forever.

You spend countless hours on job descriptions, hiring rubrics, and checking references.

You put candidates through the gauntlet: coding tests, whiteboard problems, panel interviews, culture interviews, and so on.

If they make it through, then you roll the dice and make them an offer.

Despite all your best efforts, sometimes you lose the gamble and make a bad hire.

Hiring often seems like the game of Minesweeper – avoid the landmines of “bad hires,” or you lose.

Consider a new paradigm

What if the concept of “bad hires” is more harmful than helpful?

Maybe it creates a false dichotomy of ‘good hires’ and ‘bad hires’ causing us to give up on ‘bad hires’ too quickly, or stick with ‘good hires’ too long?

And, what if it makes it too easy for us to avoid the blame for problems in our hiring, on-boarding, training, and integration processes?

 

It’s sure easy to point fingers at a bad hire, especially after they’re gone.

And while this is comfortable, it robs us of opportunities to improve our team, tools, environment, and process.

 

Maybe there aren’t any ‘bad hires,’ similar to the idea of ‘no bad dogs’ or ‘no bad kids.’

Maybe there are just people doing their best in a new environment, with what they know.

 

If that were true, we might stop blaming them for being a ‘bad hire.’

And ourselves for not avoiding the land-mine.

 

Instead, we might look at the environmental conditions, and consider how they might be impacting everyone.

Because #CommandAndControl is dead, and programmers are already the most motivated workers on the planet.

I think it’s time for the #NoBadHires movement.

 

More on this tomorrow, but in the meantime…

Does the idea of ‘bad hires’ exist where you work?

What effect could it have?

What idea might be more useful where you work?

 

Write me back – I’d love to hear your thoughts.

Best,

Marcus