By Kevin E. Breidenbach - 16 April 2009
I’ve been involved in recruiting technology people for some time. Although not a recruiter, my role has often included the hiring (and less fun, the firing) of staff for a number of different organizations. I now find myself in a technology group – and when I say "group," I mean "me" – that has to embark on the task of building a team that can supply the technological solutions that the business partners need. I plan to use the knowledge I’ve learned over the past umpteen years to the job, and thought that it might be fun to impart that information on all of you.
Common Mistakes Made When Hiring People
Hiring for Hiring's Sake
Your team has been working 80-hour weeks for the past 6 months when suddenly you’re given an enormous budget to hire more people. (I know – a dream in this economy, but it's been known to happen.) Suddenly the recruitment engine kicks in full swing. Job requirements are posted, search firms are given their marching orders, and resumes flood in. Your team doubles in size in just a few months, but you’re still working 80-hour weeks. What on earth went wrong?
Did anybody look at why your team was working 80-hour weeks in the first place? Could it be that they have no process? Could it be that there was insufficient domain knowledge? Could it be that your team has a number of “net negative” people? If any of those are true, then just hiring new people is not going to solve the problem. More than likely, it'll just make it worse.
If you don’t have a process in place, new people aren’t going to be able to contribute that quickly and will get lost in the sea of misguided effort. If you don’t have sufficient domain knowledge, you'll have nobody to identify who the right people are to hire, and then teach them what they need to know once they start. If you don’t identify and remove net negative developers – people who contribute less than the work they create for other people to do – you don’t eliminate disruption within the team. This all may seem obvious, but all too often, nobody looks at the root cause of a problem before they set out to solve it by hiring.
Who's Doing the Hiring
A very wise person once told me of the “As hire As, Bs hire Cs” conjecture, and I’ve seen it in practice. Someone at the top of their game - an "A" person - is more likely to hire someone who has equal or better skills than they have, than they are to hire someone who is crap at their job. This is because highly competent people don’t see hiring other competent people as a threat, but as a way to learn. Incompetent people see hiring competent people as a short path to being laid off. Think about it: would Rex Grossman hire Tom Brady when they could be competing for QB?
An “A” candidate isn’t necessarily somebody strong in a particular skill (unless that is a requirement). It could be someone with a desire to learn, who spends their spare time researching technologies, and who has confidence in themselves. Aptitude and attitude, more than skill or knowledge, are what separate the top-tier from the middling performers.
Do I Really Need a Specialist?
I’ve heard excuses from developers at all levels about why things don't get done. “There’s nobody to design the database”; “We desperately need a GUI developer”; “My wife just had a baby and I’m on paternity leave”. Okay, that last one is valid, provided the guy is actually married and does have a newborn.
Seriously though, many of those excuses come from net negative developers who are content with knowing what they know, prefering the comfort of working in a silo to learning and growing. If they have no interest in growing their personal capabilities, do they really have any interest in growing your organization?
Think about the real need you have for different specialists. For example, do you have enough database work to warrant hiring a full time database administrator? Do you really need a specialist GUI developer when you only have two screens to produce? How much use will you really get from him, versus how much work he’ll manufacture for himself to do? Could a developer who’s eager to learn, working with some outside expertise for a bit of coaching and auditing, get the work done more efficiently? A small team of poly-skilled generalists will always outperform a large team of specialists in silos.
The fact is that some specialists only want to advance their specialization. If you don’t have that much work for them, they’ll be expensive ornaments at best, or create a perpetual (and costly) maintenance legacy at worst.
Before Hiring
Before you start hiring, get your house in order. Make sure that you really need new people, not that you have the wrong people, or have a complete lack of process. If you do hire, make sure the right people are doing the interviewing. Finally, make sure that any specialist you add will make your team stronger than it would be from having people with a wider collection of skills. The business will appreciate it if you don’t use their entire budget on useless hires. They’ll also appreciate it if your team gets more stuff done, instead of having new faces to blame.
About Kevin Breidenbach: Kevin has a BSc in computer science and over 15 years of development experience. He has worked primarily in finance but has taken a few brief expeditions into .com and product development. Having professionally worked with assembly languages, C++, Java and .Net he's now concentrating on dynamic languages such as Ruby and functional languages like Erlang and F#. His agile experience began about 4 years ago. Since that time, he has a serious allergic reaction to waterfall and CMM.
No comments:
Post a Comment