There’s a great chapter on hiring in Peopleware, by Tim Lister on Tom DeMarco. It starts by demonstrating how most managers would hire a juggler:
Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.Manager: Do you work with flaming objects?
Candidate: Sure.Manager: …knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.Manager: Do you have a line of funny patter that goes with your juggling?
Candidate: It’s hilarious.Manager: Well, that sounds fine. I guess you’re hired.
Candidate: Umm…Don’t you want to see me juggle?
At Red Gate, we heed the point that the book goes on to make. In an interview, we test the skills that people claim they have. If we’re hiring for a developer, we ask them to write code. Testers test something for us, sales people sell us something, we ask designers to design, and so on.
There is a chasm between the abstract and the concrete; between the meta and the specific. Ask somebody applying for a sales job how to sell something and they’ll speak fluently about finding out the customer’s needs, how to handle objections and how to close the deal. Ask them immediately afterwards to sell you a computer and they’ll jump straight in and try to sell you an iMac with not even a nod to finding out why you want a computer. No matter what they say should be done, most designers ignore users, testers don’t test boundaries and marketers don’t segment.
There is, however, a limit to this technique. It only works well when the essence of the job can be distilled and presented as an interview task. This fails when the job is more ill-defined; more amorphous. Project management, say. You can ask someone to code in an interview, but can’t ask somebody to project manage. You can’t present them with a group of people and a project behind schedule and say "here, project manage this for half an hour". You’re inevitably reduced talking about how they’d handle certain situtations, or how they handled them in the past, not actually doing the task.
I can see a few solutions to this problem:
- Avoid the problem. Always hire for these roles from within. This has the disadvantage that you often end up moving talented technical people into roles they’re not suitable or ready for. Hiring people externally is a good way to bring in fresh points of view. If you always appoint from within then you risk an in-bred culture / process.
- Accept the problem. Do your best, but acknowledge that many people you hire won’t work out and you’ll have to fire them. The disadvantages – commercial and human – to this approach are obvious.
- Only hire based on personal recommendation. If somebody you trust can vouch for the person you’re hiring then that removes a lot of risk. However, it also reduces the pool of people you can hire from. This is a severe restriction.
- Insist that the people you hire are hands-on. This isn’t a complete answer, but I hire people who have something to offer than pure management. They need to be able to demonstrate they can roll up their sleeves and contribute directly. I don’t hire people who stay aloof and refuse to engage directly with the tasks their team do. Project management isn’t (just) about Gantt charts; people management isn’t (just) about personal development, performance reviews and team meetings. These hands-on skills can be tested for, but although they’re necessary they aren’t sufficient.
However, I don’t think these solutions are acceptable. If you’ve got any better suggestions on how to hire project managers / development managers / support managers etc. then post them here.
Enjoyed this post? Subscribe to the RSS feed.