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=
I met Kevlin Henny back in 2007 at the PHPUK Conference in London. (For a year or so I called him Kevin Hennly until I finally got it right) One day out of the blue, Kevlin droped me an email and invites me to participate in a new project he’s working on for O’Reilly, a collaborative book called “97 Things Every Programmer Should Know“. Not being one who is ever short of advice and opinions to give, I gladly submitted two entries that eventually made their way through the editing process and into the final book.
