Hiring Qualms

Thus one reason HR survives is that its existence makes hiring decisions pretty easy: if Dick and Jane and Harry are all pretty much peas in a pod, you risk essentially nothing by picking one at random

In an ideal world, the senior IT executive in an organization is a hands-on leader who understands the realities of daily operations and cross-trains his people both to develop their skills and to create opportunities for them to contribute in unanticipated ways.

Unfortunately there aren't many organizations like that - instead almost every time I've had to either make, or contribute to, a hiring decision external factors have out-weighed the real job related ones.

Most of the time those are organizational: things like the HR policies I discussed yesterday, or the organizational absurdity that longer term employees claim to have earnt the right to work on development projects thereby consigning the new hires to maintenance and other low status work - meaning that we retrain kids right out of school who know all about things like LAMP and object modelling to maintain thirty year old COBOL/CICS/DB2 stuff while retraining our COBOL warriors to didle ineffectually with Apache, Linux, and PHP.

Sometimes, however, the decision gets affected by personal issues that have no factual relevance to the decision. In one case, for example, I knew perfectly well who the best applicant was; unfortunately I also found her insanely attractive, and so hired a guy who was clearly nowhere near her league when it came to making things work, but wouldn't get me in trouble either at home or in the office. In another I got irritated by an irresponsible tail gating idiot in a black Honda on the highway and saw the same, or at least a similar, car in guest parking when I got there -and I'm sorry to say that candidate didn't get a fair hearing. In a third case the senior people in another office had selected a handful of candidates for us to talk to - and the guy I ranked lowest on learning potential went back to school instead of working for us, got a ph'd in computer science, and now teaches at the University of British Columbia.

Oddly enough, firing people is a lot easier than hiring them. Why? because it's easy to spot idiots or people behaving counter-productively when they're inside your group, but almost impossible to spot the really valuable people among a larger group of applicants.

Thus one reason HR survives is that its existence makes hiring decisions pretty easy: if Dick and Jane and Harry are all pretty much peas in a pod, you risk essentially nothing by picking one at random or by having a team of juniors interview each one and make the decision for you - sure you get mediocrity, but it's the company's money and hassle free.

But when you truly have to choose between two or more people each of whom has some unique value to offer your team - then things get a whole lot harder.

One issue that's becoming both more common and harder to deal with is age-ism. You may be willing to hire somebody older than you, but how will that person fit with your team? If a couple of them are still looking for daddy, getting a grey hair onboard could disrupt their path to independence - to the point of silently imposing a heirarchy where you don't want one - unless, of course, he's good enough that he'd gain team credibility regardless of age, in which case you want this to happen. And if that isn't conflicted enough, consider the reverse: you've got an established system that works, your average team age is in the low thirties, and this twenty-two year old walking bag of hormones right out of college looks like a good choice...

The problem comes down to this: when you hire Dick instead of Jane you're making a decision between two sets of futures, both of which have the potential to work for or against your personal and organizational goals. So once you get down to a few candidates, any one of whom could do the job and all of whom have been judged broadly acceptable by other members of your team - try to go the extra mile: see if you can bring them in for a few days on per diems to meet with key users, work through something of substance with other team members, and generally get a feel for the organization.

Nine times out of ten, they'll make the decision for you -because some won't play, some will lose interest in the job, one or two will be clear stand-outs, and somebody will offend greatly against local mores - thereby presenting you with your final pre-hiring challenge: when to go against advice.

I've been on both sides of this: as a member of a team all of whom described the boss's chosen candidate as an [expletive], and as the guy who made the decision to bring just such an [expletive] on board despite both staff and user objections. In the first case, the boss was wrong - in reality the guy was as clueless as he was arrogant and spent most of his time creating trouble for the real sysadmins/DBAs. In the second, we first made him a team of one - but eventually integrated him successfully into overall operations because he more than carried his weight - and gradually adjusted his attitudes.