The Tyranny of the Label

Mr. Orton was addressing Alexander Bell about his new invention, the telephone. Orton referred to the phone as a toy. The device was labeled. It was boxed. There was no longer any guilt. With a simple rejection letter, Orton made one of the greatest business blunders in history.

Sometimes a label can simplify a problem. Sometimes a label makes it worse.

In my Big Online Book of Making a Linux Startup, I show that there are no short cuts to hiring. I've heard of IQ tests, skills tests, multi-tier interviews, head-hunters and, of course, the traditional resume. None of these short cuts are effective means of evaluating candidates. You can't judge a book by its cover, even if you measure the cover, have more than one person look at the cover, or are so lazy that you pay someone to chose a cover for you. People are too complex to label so superficially.

Years ago I applied for a job for a Toronto financial company, and the HR person asked, "What are you?" I said I had skills in many areas, including technical writing, programming, AI and complex problem solving, UI design, team management, customer support, coaching and computer administration. I had written books, worked as a programmer, administrator and teacher. She was perplexed. "Yes," she said, "but which of those ARE you?"

The answer is, of course, all of them and much more. The same is true for all human beings.

In his book "Slack", computer consultant Tom DeMarco talks about the myth of the fungible human resource. When "personnel departments" became "human resource departments", there was a change in how employees were viewed. Originally humans were viewed as capital which is invested in and maintained. Now employees are treated as fluid resources like paper or electricity. Humans could be moved around, exchanged or disposed of with no consequences. No hiring costs. No training costs. No cost in lost situation knowledge. No guilt. But the label was wrong. Companies lose a great deal of money when they treat people as low-value, interchangeable units just as if they treated buildings or other capital investments that way.

True computer skills are difficult to label because most people don't know what they are looking for. It's not a matter of software or hardware experience. There is no such thing as a "Java programmer" or an "embedded programmer"--or even a just a "developer". That's why traditional hiring methods don't work.

Instead, true skills are skills like the ability to rationally break down problems. The ability to understand a situation clearly. The ability to express oneself simply and concisely. The social traits for team work (responsibility, kindness, humility, patience, courage and the like). The ability to manage complex problems without getting confused. Basic ethics to protect yourself from destroying angels. These true skills don't come out on resumes, on-line applications, quizzes in foreign environments or multi-tier interviews.

In "Accidental Empires", columnist Robert X. Cringley talks about "The Tyranny of the Normal Distribution"--that is, the problem of rare, "ultrasmart" people that are not recognized and hired. Cringley spoke of an encounter with Charles Simonyi, a man with the rare ability to manage in his head problems with more than "200 pieces of data...and 30 data points". This is something that, perhaps, only one person in an entire city or region could do. Clearly Simonyi is exceptional and a coup for any company who hires him and is an asset to many different IT jobs. But if someone like Simonyi went into a typical job interview, you can bet that he could be labeled and placed into a generic bin called "programmer".

When I started PegaSoft, one goal was to learn about the best Linux developers in Toronto. To get to know someone takes time--hence the monthly dinner meetings. This was not merely about who I would hire to do a project, but also about getting to know their complex personal traits, So there's one guy I know would work for me in a minute if the pay was good and the work was intellectually challenging enough. There's another who would work for me but would need me to provide structure and give him encouragement. And there's another guy I know who talks about how he could do better work than others but he never completes a project. And another blames others for his mistakes and lashes out when he needs to upgrade his skills. There is no short cut to learning this kind of knowledge of real people.

When my father wanted to hire someone to run the world's first mechanical grape harvester, he hired a man who shot pool at the local bar. Why? Because the harvester is a machine that requires extreme eye-hand coordination and the ability to manage 7 or 8 different factors at one time. My father didn't see the label of "pool player": he saw a man with the skills needed to bring financial success.

How can you find the talented people you need for success? Take the time and care to see the complex way they can benefit your organization? Or list all the resumes in a generic box called "programmer"? You decide.

Talk back on the Linux Cafe.

January 20, 2006 

Lone Coder RSS Feed
Mark this page with a Firefox Live Bookmark for automatic notification of new articles!