Don’t Get Screwed! How to Hire and Manage Developers and Programmers.

I just fired my latest web developer!

Over the years, I’ve worked with quite a few programmers/developers on various projects I’ve wanted to develop. On the smaller projects, I’ve typically been very successful in finding people who can get the job done. Unfortunately, however, on the larger projects, I’ve had more failures than anything else.

The problem I’ve found has been that overall, many developers and programmers don’t live up to the hype. I will use my latest experience as an example that I hope others can learn from.

I recently heard about a website similar to Guru.com and Scriptlance.com called oDesk, where folks can find and hire developers for their projects. The site, in my opinion, is vastly superior to the other sites for a few reasons — primarily because you can track the work of your developer with screen captures and video camera captures, but also because the site has a series of tests for different areas of programming, language, and design, where you can see how skilled someone is.

Recently, I hired someone who I had worked with in the past on a fairly large project. He had demonstrated to me that he was competent and trustworthy in his handling of the initial job. In developing our plan of attack and in the first few days of the job, everything was great and going smoothly. Unfortunately, I quickly learned that he wasn’t someone to be trusted. He disappeared for 2 weeks in the middle of the project, and I was too stupid to fire him. He promised to meet a certain number of weekly hours, but let me down and achieved only a small fraction of that number, and again, I was too stupid to fire him. He then disappeared for 3 and 4 days at a time, 3 more times before I had finally had enough and fired him. He couldn’t explain his disappearances or inability to perform. He was unable to complete in almost 7 weeks that which should have been completed in one.

I realize that I messed up big time with him and let him walk all over me, but in doing so, I learned my lesson. Hopefully the rest of you don’t have to get walked on to learn the same lessons . . .

What Lessons Did I Learn That You Too, Can Learn From?

• References are often somewhat useless! I would have recommended this guy to anyone after he completed the first job with me. He would have gotten glowing reviews across the board, but don’t be fooled. Human nature is unpredictable. Many people have a nasty habit of disappointing you if you give them the chance. You have to take referrals with a grain of salt, knowing that the person may screw up. Just because they come with recommendations doesn’t mean that they will perform for you. Don’t be afraid to deal with the situation if this person doesn’t work out. I also think it is extremely important to let the person who referred the programmer or developer to know whether or not they did a good job. Unless they are aware of problems, they will likely go on recommending them to others. Just because you got screwed, don’t allow others to get harmed as well.
• Use ODesk! One of the other great features of this platform is that your provider is billed weekly. You don’t need to pay anything up front as a deposit. By paying weekly, you only get charged for the work that has been done in that week. If the provider doesn’t work (and you can track this with the screen captures/video cam snaps), he doesn’t get paid. Had I hired him through another site or directly, he would have likely demanded some kind of up-front deposit, which I would likely have never gotten back once I fired him. Using ODesk actually protected me.
• If your developer isn’t performing, fire them! I didn’t want to do so because I’m on a deadline and I know that bringing a new person in takes time, but it is worth the time if the new person is going to perform to your needs.
• Set timetables. The minute I realized that the developer was weeks behind, I should have handled it. I kept hoping that things would change, but learned my lesson. If the developer can’t keep to a timetable that is reasonable, then it is time for them to go bye, bye.
• Don’t get emotionally involved! This was probably my biggest mistake. By getting emotionally involved, I kept allowing myself to will that things would improve. Hope and will aren’t going to make someone do the necessary job for you. Once you let your emotions affect your decision-making, you abandon the ability to make clear-rational decisions.

I could probably cover many more lessons that I learned, but none would be as important as the four I just mentioned. I’m in the midst of searching for a new developer and, although I know that I just wasted 6 weeks of my time, I also know that I’m much more prepared to deal with the next developer I hire.

BTW – If anyone knows of a great Ruby on Rails developer, please let me know!