Sean Landis writes about why hiring is important for software organizations and and what the challenges are in the article, Hiring as a Core Competence:

http://www.artima.com/articles/hiring_as_a_core_competence.html

Do you think hiring should be considered a core competence of your organization?

Who do you think is best suited to evaluate top software developers and testers?

Do you agree that whom you hire will change your organization for better or worse?

What areas of the hiring process does your organization have most trouble with?

Does your organization have a low acceptance rate for the better people you make offers to?

I disagree with the notion that ”great organizations begin with great hiring.” I believe that great organizations begin with great leadership. Because the term leadership is a bit general, I’ll add that it includes great management. That means understanding the organization's goals and believing in them because the manager knows that they are worthy. This skill brings with it an understanding of the kind of people required to achieve those goals. Knowing this makes the hiring process a lot easier - almost a given. I think your statement is much too simplistic and it shows the same reductionism that is rampant among the management population. Saying something is simple doesn't make it so.

The most productive shop I ever worked in used a technique we can call "Agile Firing". In this shop, if a developer's code containing a defect makes it to production, the developer and the QA person get warning letters the first time and canned the second time. If the developer passes code with a bug to the QA person and the QA person catches it, the developer gets the warning letter or fired. Every place I have worked since has been a nightmare, always on the verge of being overwhelmed by their defects.

Most IT managers love defects. Defects give them something to do. I had one manager and although I don't think he ever said it out loud, his management theory boiled down to, "We don't solve problems, we manage them".

When hiring, mistakes are bound to be made. Firing can be much more accurate and precise. Take thirty seconds and try to imagine what buildings would look like if they were built and maintained by software developers in league with IT managers. I think most will conclude that few developers and managers would deserve to have jobs.

Greg, that's a strong opinion, strong measures. From your comment I can see you're neither with that company anymore. That surely proves something, but I don't know -- about them or you? Well, at this point I'd leave the question unanswered.

"After that, one of the most important jobs of a software professional is to help hire the best. HR and management have a role, but it is a support role; the front line lead developers and testers are the best equipped to evaluate others like them. "-Sean

Is this statement true? Is there some evidence to back this up? Specifically "front line lead developers and testers are best equipped to evaluate others like them"...

I agree with the premise of the article "Hiring right is critical", but some of the statements seem inaccurate.

Michael, do you mean saying something simple like, if you have good management hiring is almost a given? I could have said, "Great organizations begin with a business license." Or "Great organizations begin at conception."

Surely great hiring doesn't happen unless there's a vision and goals for the organization. Someone must do the hiring, but a great leader does not an organization make. A skillful leader doesn’t necessarily know who to hire or how to hire. Like anything else, hiring is a skill and it's not the same as leadership or management.

A leader can contribute to success in hiring through conviction and commitment. These are driven by the goals of the organization. In the book, I use a more general concept of “organizational values” to gather up the various forces that motivate great hiring.

If a leader with vision and goals brings conviction and commitment to the hiring effort, great hiring is a more likely outcome; but it’s not a given. If that leader also happens to have the skill to hire say, software developers and testers, then that is a bonus.

Lee, who would you suggest is more capable of evaluating high-skill candidates if it isn’t employees with about the same or greater skills?

For example, a recruiter who is well trained in the art of hiring can only go so far in determining the qualifications of a software developer. To accurately evaluate the candidate up to the standards of a skilled position, someone with relevant expertise in the domain will be required. I generalized that group of people using “front line lead developers and testers.” Some organizations are fortunate to have relevant expertise in management or elsewhere.

The point I wish to make is that people with sufficient skill and experience in the domain are best suited to evaluate a candidate for a job in that domain. They may not have the hiring skills yet, but they do have the domain skills. I believe that’s a prerequisite. These folks are usually technical leads of some sort. Capturing all the organizational variations in title and role would have been daunting task, so I generalized.

Hi Sean, So you seem to imply that lead software developers are the best people because they have the technical skills and the knowledge of what the job requires. Two observations:
1) I too often see people elevated to positions like leads who are not competent.
2) I too often see people at these positions who lack the ability to obtain the skills you indicate are necessary to be able to evaluate talent.

I agree that "Some" lead software developers may be able to do this role, but I would not be comfortable with this being part of the skill set of a lead software developer.

I also agree that hiring the right technical people is critical. I just see this as an art, not a skill that any one can develop.

Maybe if we had some statistic that stated over all roles and positions the Technical Lead Developer position consistently show that <XX>% excel at evaluating talent for an organization. I was curious if you had any statistics.

Great dialoging with you!
-Lee

Hi Lee, Certainly people are promoted beyond their ability. I did say, “sufficient skill and experience in the domain.” I take that to mean they are qualified. If they aren’t, that’s a different problem.

Another reason I used “lead” is that some variation of that role is often directly responsible for people they hire. I think it is important to have that responsible person involved in the hiring process. Likewise, other “leads,” even if they are not hiring, at least have the understanding – the empathy – required to enable the to do a better job. That said, not all lead developers hire equally well. That’s an interesting challenge for a company. I am convinced that anyone worth keeping in that sort of role can become better at hiring.

I also agree hiring is an art: “…a recruiter who is well trained in the art of hiring…” I actually prefer “craft” as it embodies art, science, experience and practice (skill).”

I am afraid I have no statistics on who does the best hiring. I would be intrigued by anyone who claimed they could produce statistics that could be interpreted in any meaningful way.

This reminds me of the movie “Top Gun” where the very best Navy pilots are brought together to compete. Two grizzled veteran flying aces judge them based on their skills as fighter pilots. These guys don’t fight on the battlefield any longer but they still (obviously) have their skills. The civilian contractor is in a position to evaluate the pilots in some areas but, as the movie makes clear, not in many of the areas that really matter.

Greg,

I would hate to work anywhere that followed the strategy you outline. Addressing quality is not about punishing people who make mistakes. The approach you describe is far more likely to end up with bugs being swept under the carpet than true organisational learning.

As it happens, I wrote an article about this a few months ago, called "Forgive and Remember" in PragPub magazine:

http://pragprog.com/magazines/2009-12/forgive-and-remember

Paul, I know what you're saying but it wasn't that way. Developers always got maximum cooperation, We didn't spend all out time fighting but but instead doing new development. Nothing was ever swept under the carpet. In the two years I was there, one guy left. I left when I got a job opportunity in Miami.

I guess my previous career as a submarine nuclear power plant operator prepared me to live in a world where mistakes have consequences.

I've had two jobs where there was "organizational learning". These two jobs were where mistakes had consequences. I would go back to that employer in a minute but the guy who fired people retired and the place went to heck. Now they do almost nothing but try to reproduce bugs.

The dilemma of many SW development projects is that they get started by "domain experts" who know their subject but have little coding experience. They produce tons of ugly spaghetti code and while they do care about functional correctness, they don't care much about code quality. The further evolution is dominated by the wish of scaling up: adding new features to an existing product.

Understanding specs and hacking new features quickly into a code base created by other people who might not even attend to the project are the most relevant skills of a programmer in industrial practice, which is not determined by the drive of writing "beautiful code". Discipline is added by means of demanding code documentation, testing and some bureaucratic protocol. The project leader is often a very skilled person who has to mediate pressure from above and sacrifices the future for the present i.e. technical debt accumulates freely with every new feature, making it increasingly difficult to pay back even little.

Within this setting those people are added to a team who are the most promising in terms of the least delay of getting them trained on the code base. The other relevant factor are of course the costs of the labour commodity. Hiring people isn't an art but a function of the candidates prior experience and costs. The human factor in hiring is still needed though to weed out the psychopaths and the blowhards, which can't be detected by bots.

Few companies like Google or Microsoft are still interested in generic skills and let the candidates solve programmer specific IQ tests, like algorithmic puzzles. Others like Jane Street Capital try to attract CS PhDs by using OCaml.

Most commonly the demanded skills are atomized and uncountable and you match them on random, just like your marketable experience equals a random trajectory through a discrete universe of skills.

Kay, You say, “they get started by ‘domain experts’ who know their subject but have little coding experience. They produce tons of ugly spaghetti code…” I assert that this person is unqualified for the job. Is that a hiring problem or an organizational problem, or both?

Then you say, “Hiring people isn't an art but a function of the candidates[sic] prior experience and costs. The human factor in hiring is still needed though to weed out the psychopaths and the blowhards, which can't be detected by bots.” This is precisely what I mean when I say companies aren’t convicted that great hiring is critical and aren’t committed to becoming good at it. With this perspective on hiring, negative outcomes such as the one you describe are to be expected.

Sean Landis said:
"A skillful leader doesn’t necessarily know who to hire or how to hire. Like anything else, hiring is a skill and it's not the same as leadership or management."

Sean, I liked your article and agree with much of it, but I disagree with the above statement. In my experience, recognizing, attracting, and keeping good talent are necessary skills of a good leader. A "leader" who does not know how to recognize high skilled and high quality people will soon have an organization staffed by incompetent people. After reading your article, we know the end result of an organization with even a few incompetent employees.

A "leader" who does not know whom to hire, will not be able to recognize good talent, and will likely fail because of symptom #2 of the Dunning-Kruger Effect.

http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Rich, I think we are in violent agreement. The context of my quoted text was to refute that good management and leadership make great hiring automatic. I disagree. First, that leader must learn to hire at some point to become great. I suppose one might define a great leader as already having acquired those skills. “Leader” is so overloaded. I consider the “lead developer” I referred to as a leader. I consider a director and a VP of IT leaders. Which is most qualified to evaluate a candidate’s technical skills? Which is most qualified to evaluate leadership skills?

Sometimes great leaders in particular roles will fail to hire the best because of the first symptom of the Dunning-Kruger effect. They may be great leaders, but they are no longer sufficiently skilled in development technologies to distinguish great developers (Although they believe they are).