tinyurl.com/6nqkl -> msdn.microsoft.com/Longhorn/default.aspx?pull=/library/en-us/dnsoftware/html/software07072004.asp
See This in MSDN Library Hazards of Hiring Eric Sink Software Craftsman, SourceGear July 8, 2004 Summary: Eric offers guidelines for handling tough hiring decisions in a small ISV.
This column was one of the most popular things I have ever written. People seemed to really enjoy reading about my screw-ups. As human beings, we are fascinated by the failures of others. In the many e-mails I received about that column, one of the most common questions was why didn't I list any hiring mistakes. "Eric, is it possible that you have simply never made a mistake in a hiring decision?" It is one thing for me to air my own idiocy in public, but quite another thing for me to recount tales that might hurt someone else. Nonetheless, hiring decisions are tricky, and I think I've learned enough to say a few worthwhile things on this topic. I'll start with four general guidelines for how to proceed with a hiring decision. After that, I'll finish the article by saying a few things about the specific challenges of hiring software developers. For small independent software vendors (ISVs), my rule is: Don't fill a position until after the need for that position is painfully clear. In other contexts, it often makes sense to "staff up" in anticipation of growth. Your investors didn't give you millions of dollars because they want their cash sitting in your bank instead of their own. They expect you to grow your company aggressively, and that often means hiring more staff. But in a small company that is funded by its own revenues, it is almost always a mistake to hire for a position before it is absolutely clear that hiring is the right thing to do. You are expecting lots of new orders, so you decide to hire another customer service person to be ready for the deluge of phone calls. Better idea: Have one of your existing staff take those calls, or take them yourself. Don't increase your payroll until you are 100% certain that you have a permanent need for one more person than you have now. Several years ago, I decided to get very aggressive about growing SourceGear "to the next level". We made several new hires, including a human resource (HR) person. We convinced ourselves that the company was going to be growing so fast that we needed an HR person to help coordinate policies and benefits. But the fact remains that our company was not really big enough to have a real need for a full-time person in HR. And then the dotcom bubble burst, and SourceGear never did get that big. When we evaluate a candidate, we are basically just trying to predict whether that candidate will be a success in the position being filled.
So, we use various indicators that we believe will be correlated with future success. Sometimes all our indicators are positive, but the employee just doesn't work out. Last year I helped a charitable organization hire a new staff member. There was no question he had the necessary experience to handle the job. Shortly after Wilbur started on the job, things turned surreal. Wilbur is clearly a sharp guy with solid abilities, but this situation simply didn't work out at all. On the other side of the coin, sometimes we miss out on a great employee because our indicators steered us away. We turn down a candidate, and we don't hear where that person ends up. There are federal statutes and there may be state and local regulations as well. I am not an attorney, so I will not even attempt to explain these laws, but it is very important that you understand them. The various materials from Nolo Press are usually a good starting point for beginning to understand legal matters.
Even still, it is always advisable to consult a local attorney. One final remark: Even if you discover that you are exempt from the laws due to the small size of your company, it is well worth your time to understand the law and begin making habits out of following them. In most situations, complying with the discrimination laws will actually improve your decision-making anyway. If you want to consistently make the worst hiring decisions you can make, just make all the decisions by yourself without listening to anybody else. But if you want wise decisions, get a variety of opinions and different perspectives. In my own hiring decisions, I make sure at least one of those perspectives comes from a woman in my company. The simple fact is that the software industry has a lot more men than women.
Julia Lerman noticed that the TechEd speakers list had more people named Brian than women. Our field is perhaps 90% male, and that means I have to work a little harder to get balance on this aspect of our hiring decisions. I've observed a pattern over the years, and of the bad hiring decisions we've made, many of them happened when the decision was made entirely without a woman's voice. Fortunately, my approach has worked well in ways that I could not have anticipated. In 1998, SourceGear was looking to hire a full-time person in technical support. The decision was primarily being driven by myself and one of my co-workers named Mary. Mary and I disagreed on which candidate should be chosen. I deferred the decision to Mary, confident that I would eventually be proven right. But the person Mary chose turned out to be one of the best employees we've ever had. Hiring Programmers: The Usual Advice Most of the writings on the subject of hiring programmers tend to sound the same. Please understand that I am not advising anyone to deliberately seek out mediocrity. We obviously want to hire the most talented and experienced people we can. Your decision will affect your team, and it will affect the individual.
Joel says, "It is much better to reject a good candidate than to accept a bad candidate. The problem isn't so much with the advice itself, but with its tendency to be misunderstood. When applied with no additional precision, the primary effect of the usual advice is to create a sense of arrogance. This effect is especially common among programmers, since elitism comes naturally to us anyway. When we hear that we should "only hire the very best", we internally translate this to mean: The "very best"? Obviously, I should only hire people who are as gifted, as smart, and as good-looking as I am. After all, why should I pollute my perfect team with riffraff? It is not surprising that this attitude provides a poor framework for hiring decisions. The usual advice works much better when it is understood quite differently: I want to build the most effective team that I can build. When I hire another person for my team, my goal is not merely to make the team larger. Each person I hire should be chosen to make my team better in some specific way. Rather, I am looking for someone who is more talented than me, in at least one significant way. The very worst kind of manager is the one who feels threatened by his team. Consciously or not, he is afraid of those who are "the very best", so he consistently staffs his team with people who will not challenge him. I suppose he might be able to get away with this in a big company. After all, I doubt that the Pointy Haired Boss in the Dilbert comic strip was created with no source of inspiration at all. But things are very different in the world of small software companies. If you are the founder or "chief geek" in your small ISV, take a careful, honest, and objective look at yourself. If you are the type of person who feels threatened by your own staff, stop and rethink. Until you move yourself past this problem, you have exactly zero chance of building an effective team. The real point of the usual advice is not to inflate our egos--it is to remind us that we should not be afraid to search for the best people. But we still need a more specific understanding of what the word "best" really means. Look for Self-Awareness The "very best" people never stop learning. When I evaluate a candidate, one of the most important criteria is what I call "the first derivative". Is this candidate moving forward, or have they stagnated?
This is often the strongest predictive indicator in the hiring process. I'm not saying you should just hire people who want to succeed. I'm talking about hirin...
|
http://csua.com/feed/