Two Rules for Hiring/Retaining Developers
Dear Reader,
Most of you know, but some of you may not know, that one of the consulting services I provide is helping people identify and hire quality PHP programmers. I’ve been hiring developers for a long time now and inevitably, someone will ask me in a conversation, “How can I find good programmers?” Since I assume they know that I charge people to do this, I always refrain from the obvious answer, hire me.
However, after having a variation of this conversation for the then thousandth time recently, I decided to lay my cards out on the table and tell everybody the secret. Feel free to use this without hiring me but remember that if you get stuck, I’m here for you.
Looking back over the 200+ developers I’ve hired in my career as a manager, I can honestly say that hiring and retaining good developers can be boiled down to two rules. Everything else that goes into the process is just details. (And I do want to apologize to my friend Leslie who is in HR. I do not mean to minimize your job by saying you are a detail!) :)
Developer Hiring Rule: Only hire developers you trust.
I’ve laid out elsewhere my process for hiring developers, those are the details. The decision though as to who gets hired and who doesn’t comes down to a matter of trust. To put it a little more bluntly, trust your gut/instinct. As with any hiring manager, I’ve made bad decisions, in all but one case that I can think of though, bad decisions were made because I did not trust my instinct on a person.
This is an especially important rule for small businesses. You may only hire one or two IT people for your entire company. Make sure you really feel that the person is a good fit, both skill wise and personality wise.
Developer Retention Rule: Trust your developers.
If you followed the advice of rule #1 then this one should come easily. I’m not advocating handing a new hire the keys to the company but your developers, more than anyone outside of your management team, will know the inner workings of your company. If you are not a software company then your IT staff will have access to a number of important facts not known to others in the company. If you followed Rule #1 then you’ve got people you trust…now trust them to do their job.
If you are a software development company this is especially important. As a matter of fact, if your company makes any part of it’s revenue stream from software development or from providing services built by developers, and you personally do not write code, you company’s fate is in somebody else’s hands. You want to make sure that you followed Rule #1 and hire people you feel you can trust and that you then follow Rule #2 and trust them to do their job.
What to do when either rule fails you.
Actually, the better question is what can you do when you failed to follow one of the rules. One of the greatest bosses I ever had gave me some sagely advice. “A sharp knife cuts clean.” If you’ve got a developer on staff that you cannot trust, get rid of them and do it quickly and unambiguously. (local labor laws not withstanding)
The #1 task is to get rid of the developer before they become a problem. The second task though is to let the rest of the team know exactly what went down, why the developer is not there and reassure them that their jobs are not in jeopardy. It always astounds me when people suddenly disappear form a corporate org chart without explanation. Does upper management (C-Level usually) think that nobody will notice? Do they think not saying anything is actually better for morale than being open and honest with their employees? remember, you’ve hired people you can trust…trust them to be smart enough to be able to handle the information.
So there you have it. If you don’t want to hire me to help you build your PHP development team, those are the two rules I use to hire and retain good developers.
Until next time,
(l)(k)(bunny)
=C=
![[Post to Twitter]](http://blog.calevans.com/wp-content/plugins/tweet-this/icons/tt-twitter-big4.png){kind=icon}
Related posts
Tags: advice, Consulting, developers, hiring, nerd herding, PHP
November 13th, 2007 at 9:42 pm
A few years ago, I started by recruiting from Open Source projects. Odds are you know of a few people with the right skills and you already have a relationship with them. Or if you don’t, you can learn about them.
Look at their commits – do they catch the subtle bugs or introduce them?
Look at their forum/mailing list activity – are they a jackass? Are they helpful? Do they just give an answer or do they work to improve clarity?
Look at their general activity patterns – are they consistently active or bursty with long silences?
November 14th, 2007 at 5:56 am
@Keith Casey: Commit quality and forum participation is an obvious one — but what conclusions do you draw from their activity patterns? “Consistently active” would suggest to me that they have a pretty basic day job with minimal “crunches” (which is possibly good luck for them but not always something they have control over), and probably just one “pet” project they contribute to regularly.
“Bursty with long silences” could mean lots of things — maybe they have poor time management skills, but also maybe their paid work is intermittent (they’re independent, contracting/sub-contracting, etc.), maybe they approach open source work as a “scratch the itch then move on” type thing, or maybe their normal job has varying time demands based on release schedules, etc..
November 14th, 2007 at 9:09 am
@Rob – Good point and you’re right, the third aspect isn’t nearly as useful as the other two, but you can still glean a bit of information from it. When they’re active, is it a bunch of little commits or is it a huge refactoring? When they’re inactive are they completely out of the picture (radio silence)? Are their contributions all over the place in terms of areas of the code or are they focused in specific modules/etc?
It’s just further information to consider and evaluate.
November 14th, 2007 at 12:55 pm
Simple, yet important points to remember when hiring!! I have the same observations as you have… Your points are all the more important for startups as they can afford that developers leaving in the middle of tough times!!
November 21st, 2007 at 1:36 am
General mistake of employers they query employees but say nothing about themselves.