You Can't Automate Judgment and You Should Not Try

I have been corresponding recently with a couple of my code monkey buddies, both hard working, brilliant developers.  They are complaining about the big applicant tracking packages employed by larger companies, that is, Oracle's Taleo, iCIMS, Bullhorn, et al.  
They complain about several things:

• duplicating information
• complicated password algorithms
• dumb questions with "N/A if no" answers
• half hour or more to apply for a job  

Yes, there are some jobs that can't and shouldn't be automated.  Stock trading.  Engineering.  Putting eyeballs on a resume.  In the new age of information, We have people doing all kinds of menial tasks like opening and filling out spreadsheets and then emailing them around, that could and should be automated.  Then we have some dumb piece of software actually making value judgments about something that even the person who came up with the requirements doesn't understand.  Here is an example: My friend Randy is applying for a web developer job.  One of the questions, after he retyped all his employment and education history that was in his resume of course, was "How much Web API experience do you have?" For those of you who don't know, Web API is nothing more than an MVC controller with HTTP methods like GET, POST and PUT.  So instead of having a Create method in the Person Controller, you'd have a Post method with the exact same implementation.  The only difference is the naming convention.  Randy has built dozens of MVC applications, but has never even created a Web API application, because there is nothing to know.  If he answers truthfully, he will certainly be passed over.  If he give s a more correct answer, like 'all of it' he could been fired down the road for padding his resume.  

This is indicative of the biggest problem in business today.  The people running a company literally have no idea what the company does or how it does it and can't even recognize talent when it comes knocking.  Years ago, the big buzzword was XML.  Every job description you read REQUIRED the applicant to be able to read and write XML.  Don't get me wrong, it's a great technology for inter-operation and essential to web services like SOAP.  However in 20 some years of development, I've never had to read nor written XML.  It's kind of like saying 'Do you have and can you explain your experience with breathing?'  
'Yes, and no' in that order.  Yes, I breathe, no, I am not going to give you a lecture in the chemistry of what happens in my lungs.  You don't need to know.

Almost 30 years ago, I was helping my father frame a house.  I stood up on the joists and he cut off and handed rafters up to me.  Having been exposed to trigonometry, I was amazed that not only did Pop remember all the tables we had to memorize for trig, but that he was doing all the calculations for the rafter length in his head.  I asked him how he did that.  He said "you don't need to know."

I stewed on that for about 30 minutes and decided that I do need to know. I got a little belligerent and more forcefully posed the question again: "How do you know how long to cut off the rafters?"  

He looked a little sheepish and replied "I don't know how long to cut off the rafters.  It's built into the carpenter's square.  Literally, you don't need to know." then he showed me how to cut off rafters with a carpenter's square.

What is the moral of the story?  Sometimes, you just don't need to know.  Randy doesn't need to know how long to cut rafters, he doesn't need to know how to breathe, he doesn't need to know XML and he doesn't need to know Web API.  You just don't need to know.

In our post at SentiaHealth.com on September 2, 2016, Theory of Constraints: An Holistic Approach To Solutions Architecture: Why You All Are Doing It Wrong and What To Do Instead, we introduced Eli Goldratt and the Theory of Constraints and its application to the software industry. Mr. Goldratt states

Technology can bring benefits if and only if it diminishes a limitation.  Long before the availability of technology we developed modes of behavior, policies, measurements and rules to help us accommodate that limitation.  If we want to be successful with the implementation of new technology, we must find the things that helped us live with the old limitations and change the rules to take advantage of the new methods.

So what we need are smart people doing smart things, not Human Resources managers looking for buzzwords and weeding out people who don't have them.  If you are going to successfully remove weeds, first you have to know what a weed looks like.  Today we are picking on Human Resources but that department is just indicative of the larger problem.  The problem is that literally nobody is taking advantage of the new technology to rid us of the limitations we have imposed to solve problems that we no longer have.  You don't need spreadsheets anymore.  Conversely, an in this example with Taleo et al, we have a limitation that technology cannot help with.  You cannot (currently?) teach a computer to read a resume.  You have to have human eyeballs and human judgement to figure out if someone is qualified for a technical job.  That is it, No way around it.  I say this, me, the guru or all things automation.

Even worse, Human Resources itself is attempting to do a job they aren't designed to do.  They don't understand the technology, clearly, or they wouldn't be using software to automate an unautomatable job.

Yes, technology can help. Your "apply for this job application" should be a link to upload your resume.  Process automated.  You don't go to the hardware store and ask the clerk about the materials used to create your wrench or hammer or pliers.  You don't know how to make those things so even if the clerk told you that this particular wrench was constructed from chrome plated, cold forged, 4140 chrome-molly billet, and he can't because he doesn't know either, you won't understand what that meant anyway.

Once more, if you can't do what I do, and you can't, don't presume to tell me how to do it.  Go get a copy of Eli Goldratt's "Necessary But Not Sufficient."  80% of any business today can be automated.  That means 80% fewer people, 80% fewer buildings, 80% electricity savings and 80% less cost.  It also means you should be able to cut the price of your product or service by 80% and still make the same profit.  I know this is true because I run MY business that way and I have automated 80% of the production of my products and I am 80% less expensive than any competition.  Know what the 20% is that can't be automated, however.  Get to know old Pareto.  Let's remove the old limitations and free the spreadsheet emailers of the world to think and innovate and be a profit center, not a cost center.  Let's think and innovate and NOT attempt to automate the unautomatable.