Finding Employees

One of the biggest problems I've seen in our industry is finding employees. Or as I like to put it "finding people who know how to get stuff done that you can be proud of". While there are definitely quite a few people "developing software" quite a few of them.. hmm.. how to put it nicely... lets just say I'm glad their not on my project team :) So how do you go about dealing with this?

There are three solutions I can see to this issue.

The first is the easiest and the most damaging. Ignore the problem. Hire whoever you can and let them code the way they have been. If they're the kind of person who learns new things on their own time then great. But if not don't worry about providing any training. Obviously I am strongly against this as you end up having buggy hard to maintain software.

The second is the hardest and it seems like every company that tries it ends up losing their way at some point. Hire only the best. The problem of course being that there is a very limited pool of "the best" and they pretty much have choice of jobs. So at some point no matter how good your environment is you're going to run out of talent. At this point you can either go the Joel route and hire globally or you give up and fall into solution #1.

The third is the hardest for a business to accept. Hire a few of the best to help train everyone else you hire to be better then they were. The reason that this is such a problem for businesses is because of the perceived and real risk involved.

The first risk which we'll call "Nobody to get work done" is IMHO only a perceived risk. There is definitely a cost involved in training your employees but the gain in productivity over the long run more then pays for the cost. I would rather work with a team of 5 who understand OO/DDD/TDD/Agile then a team of 20 guys who picked up VB.Net in their spare time. And nobody said that you had to have everyone fully trained up before they start working. For most people a few weeks of initial training followed by pairing is going to result in huge advances in skills. And before you know it they're training your new guy. Of course this assumes you hire the right people.. which is risk #2.

"Hiring the wrong people" is definitely a big risk. If you are going to be spending so many resources training someone you want to be sure they are a good fit for your team. This is also a hard risk to avoid because it's a hard thing to avoid. You want someone who fits well with your team and who is good at learning new things quickly. This is a lot harder to test for then knowing a specific language or technology. There are plenty of good resources out there on hiring people so spend some time and invest in reading them. Come up with some real questions to ask, find out what they learnt last. And make sure you bring the person in for a day to let them see your process. After all you don't want to hire someone who after a week working for you realizes he made a huge mistake and he hates it. Oh and just to cover your butt make sure you implement a 3 month review process. And don't be afraid to let people go at 3 months if things just aren't going to work. Though it is a good thing if you are honest with the person as soon as you see a problem. You can't expect someone to remedy a problem they may not realize exists.

The other big risk is people leaving. It's not much fun to spend time and resources training someone only to have them leave. My only advice for this is to get over it. People move on. Change is inevitable. Even in a utopian environment things happen and people need to leave for other pastures. All you can do is make your employees as happy as possible and let things work themselves out. The good news is that your employee is most likely going to be a cheerleader for your company if they had a good experience. One of the things I've learnt is that the developer community is alot smaller then we sometimes imagine with our world wide reach. If I want to know about any company in the city it wouldn't take me long to get a few opinions about them (I actually decided against working for an unnamed company specifically because of this).

Of course all this is just theory. So if you've actually seen it implemented or decide to try it yourself let me know how it goes/went ;)

Shane