Can a man change?

Summary: How can you improve efficiency of an organization? Hire great employees. Fire bad ones. But, first check out the references mentioned in this article.

	Madame de Merteuil:	"You are an awful man."
	Monsieur de Valmont:	"Do you think a man can change?"
	Madame de Merteuil:	"Yes. For the worse."
From "Valmont"

In the article The causes of greatness, Bob Lewis explains what makes an organization great focusing on the value of people. The article offers several astute observations, but the main idea can be summarized in the following statement:

"[I]f you want an organization that works, you'll get more leverage from hiring great employees than from any other single effort you can undertake."

Among high-tech companies, Google understands the importance of hiring quality workers better than most. In case you haven't heard about Google's hiring philosophy, it's based on two simple rules:

1. Only hire candidates who are above the mean of your current employees;
   and
2. There is no hiring manager.

Peter Norvig, Director of Google Research, explains how this approach helps Google address the shortcomings of traditional hiring practices:

"Whenever you give project managers responsibility for hiring for their own projects they'll take the best candidate in the pool, even if that candidate is sub-standard for the company, because every manager wants some help for their project rather than no help. That's why we do all hiring at the company level, not the project level."

Google's hiring philosophy seems to pay off (at least, if you believe Google employees who like to brag how smart their co-workers are); unfortunately, it is not that common. Most companies make their hiring decisions under the following premises:

1. If you do not hire someone today, your open req* may be gone tomorrow (due to cost saving initiatives, reorganization, outsourcing, etc).
2. Considering the previous statement, don't waste time searching for the best candidate; just pick the first applicant, who seems to fit the job description.

Organizations operating under such premises tend to underestimate the implications of bad hiring decisions because they succumb to a couple of fallacies.

Fallacy #1: Bad workers will do a good job if they follow an approved process/methodology/procedure (CMMi, XP, Agile, SCRUM, etc).

This belief is based on the assumption that processes are more important than people. Those who hold this belief think that any organizational problem can be solved with the help of a good process.

While processes have their place in the organization, managers tend to overestimate their value because relying on processes gives them a (false) sense of control. If your organization is not effective, it is comforting to believe that once you adopt a new process, things will change to the better. If you admit that bad employees are at the root of your problems, you will have to confront people and either make them change or control their behavior, something good managers do not enjoy doing.

The good news is that certain processes adopted by software development teams can reduce the number of problems caused by bad developers. Juval Löwy once wrote:

"Rapid development tools will make bad developers worse, because they allow them to produce bad code faster."

Likewise, by introducing certain bureaucratic overhead, processes can make bad developers less bad, because they will force them to produce bad code slower. However, if you're stuck with mediocre developers, no process will make your organization sufficiently effective. If you agree with Steve Yagge, who suggested that

"Bad developers, who constitute the majority of all developers worldwide, can write bad code in any language you throw at them,"

you should agree that bad developers can write bad code under any process you throw at them. This brings us to the fallacy of personal improvement.

Fallacy #2: Certain measures -- such as effective supervision, mentoring, a development plan -- can turn bad workers into good workers.

I'm not questioning a possibility of human self-improvement, but I cannot seem to recall a single case of a bad worker turning good. I have witnessed good workers becoming better, average workers staying about the same, but bad workers tend to remain bad.

Some bad workers do not improve because they don't even understand that they are bad (or how bad they are). Cornell University researches conducting the Unskilled and Unaware of It study concluded:

"When one fails to recognize that he or she has performed poorly, the individual is left assuming that they have performed well. As a result, the incompetent will tend to grossly overestimate their skills and abilities." (read the review)

The study suggests that people can be trained to "recognize the limitations of their abilities," but what about actual working skills, such as ability to write software? According to the findings of A cognitive study of early learning of programming, most people can't be taught programming. Nevertheless, many of those who can't learn to program somehow manage to get Computer Science degrees and eventually get programming jobs.

So what's a manager to do? To paraphrase Bob Lewis,

"If you want an organization that works, you'll get more leverage from firing bad employees than from any other single effort you can undertake."

This may sound harsh, but for organizations which do not invest in a rigorous -- a'la Google -- hiring procedure, getting rid of bad workers (not necessarily via layoffs) may be the most effective method of achieving efficiency. I'm not advocating such draconian measures as Jack Welch's annual firing of the bottom 10% of his managers (although, if implemented correctly it could be quite effective), but getting rid of people, who cannot do their job, is essential to the health of the organization. If you are interested in better ideas, read the references below.

Additional references:
How Do You Find the Best Employees for Your Company?: Things that do not help in hiring great developers.
Done, and Get Things Smart: How do you find great employees?
A Field Guide to Developers: What it’s going to take to be a top choice for top developers.
A holiday card to the industry - 2007: People, process, and technology: it's a simple formula that describes what makes any business operate.
Converting Capital Into Software That Works: A software company has to think of recruiting the right people as its number one problem.
Finding Great Developers: You can receive thousands of job applications and never see a great software developer.
Hazards of Hiring: Eric Sink offers guidelines for handling tough hiring decisions in a small ISV.
Google: Ten Golden Rules: How Google gets the most out of knowledge workers.
Hitting the High Notes: The lagniappe that you get from the talented software developers is your only hope for remarkableness.
How Google woos the best and brightest: Going from 150,000 resumes per month to 9 hires per day.
Interviewing with Google: Benji Smith shares first-hand experience with the Google interviewing process.
Iz.I.T.4.V.S.P: Suggestions how Intel should handle redeployment (layoffs).
News: Analysis of the "we hire the top 1%" claims.
No Matter What They Tell You, It's a People Problem: Usually the things that make or break a project are process and people issues.
Separating Programming Sheep from Non-Programming Goats: There are two populations: those who can program, and those who cannot.
Sorting Resumes: Looking for negative clues in resumes.
The Guerrilla Guide to Interviewing: Don’t hire people that you aren’t sure about.
Whaddaya Mean, You Can't Find Programmers?: How to find people and convince them to work for you.
Why Can't Programmers... Program?: 199 out of 200 applicants for every programming job can’t write code at all.

Bonus:
Employees Fight Abusive Supervisors with Lower Productivity: Researchers have quantified the ways employees quietly fight back despotic supervisors.

---

*	Open req is a corporate slang for an open requisition (position).