Apr 1, 2009 2
On Letting Machines Do the Work
Blade Kotelly is an interesting guy. A product of the Human Factors program at Tufts University, he made a name for himself in the field of speech recognition and literally wrote the book on it. He is currently Chief Designer at Endeca Technologies, a provider of “Enterprise Search, Information Access, and Guided Navigation Solutions.”
I met Blade about a month ago. Because he had made his name designing machines that humans could talk to and currently works at a company which builds machines that help people sort through the avalanche of data that a simple web search can produce, I was curious to discover that he at times turns to recruiters to find design talent. I asked him, “Why don’t you just let the machines do it?”
His answer was not surprising, On the one hand, he explained, good designers are difficult to find so you need to enlist assistance when searching for them. On the other hand, a big part of recruitment involves recognizing fit, and, if I understood him correctly, teaching machines to match personality types with the idiosyncratic needs of hiring managers and the peculiar nuances of corporate cultures is difficult. (Blade, if you happen to be reading this and I’m misstating the case, please set me straight!)
Oddly enough, while reading an SAP/Accenture white paper, “BPM Technology Taxonomy: A Guided Tour to the Application of BPM,” I found this point reiterated, after a fashion. In order for a business process to be automated, it is ideal that it take place in a predictable, step-by-step manner. The authors of this study point out, however, that some business processes do not play out like that. The example they use, fittingly enough, is recruiting. Recruiting, they write, “starts with a job description and ends with a hire, but exactly how all the interviews, evaluations and meetings will go is not clear at the outset.”
It’s curious that they say that it’s not clear how the interviews, etc., “will go,” since each of these events has but two possible outcomes: either the candidate advances to the next stage, or the candidate is rejected. In that sense, modeling the process is fairly straightforward: A candidate applies by submitting an application and resume. Those documents are reviewed and the candidate is either invited in for an interview or the process ends. The candidate is interviewed and the interviewer either decides to recommend that the candidate be hired, or the process ends. Etc. That is, the process indeed lends itself to a binary, forking path description wherein each step results in a (1) or a (0). (Indeed, applicant tracking systems handle the process at this level.)
The problem however is not that there are only two possible outcomes at each stage. The problem is that, aside from certain kinds of testing that might be employed, the way the outcome is produced, how the interview “goes,” cannot be easily modeled and therefore automated. In fact, the psychological factors at play, as Malcolm Gladwell has described are so unconscious, so rapid, and so irrational, that they defy automation. For this reason, many organizations turn to so-called “structured interviewing,” which can take many forms but at its most refined reduces the impact of personality quirks and coincidental affinities between interviewer and interviewed by designing questions so that the anticipated responses will demonstrate clear compatibility or incompatibility with the requirements of a given position.
Humans are really good at certain things – pattern recognition, decoding facial expressions, fuzzy logic – that are difficult for machines to do. Machines are good at processing data (performing calculations, rendering images, etc.) by running algorithms really fast. Of course, machines can also learn, and putting a human “in the loop” can help machines learn even faster. The automation of processes such as the recruitment and hiring of new employees might not be realizable yet but such systems are not theoretically inconceivable. Indeed, everyday, they become more and more possible. [Update: For a more detailed and informed discussion of the difference between computers and brains, and the superiority of the latter to the former, check this New York Times op-ed piece.]
Which brings us to the real question, which is not, “Are there processes that we cannot automate?” Rather, the real question is, “Are there processes we don’t WANT to automate?”
Image Courtesy of The Alieness GiselaGiardino²³.