How do you measure eagerness in an interview? I am not talking about simply wanting the job, but sustaining a level of engaged interest in completing work-related tasks. I perceive lack of eagerness as a serious personality flaw, an unwillingness to go the extra inch. A person with this flaw doesn’t want to work outside of the box, and, in my experience they usually have problems thinking outside of the box too. Eagerness seems related to curiosity, and curiosity seems related to creativity.
A number of years ago I was living in the Bay Area of California and went looking for another job. I talked to a former co-worker at his new company and they brought me in for an interview. The interview went well; they would hire me, and oh, by the way, did I know someone who would be willing to move to southern Arizona to manage one of their installations they had at an army base. I mentioned it to my wife who actively disliked California and the next thing I knew I was calling them back saying I was their man for the Arizona job.
In 1984 my wife and I moved to Tombstone, Arizona (population 1024) and I commuted to Sierra Vista where the army base was located. I was the on-site programmer/technical representative for –at the time– a leading edge CAD system that included an object-oriented database tied to the graphics. It had some nice features where you could pull a full Bill of Materials (BOM) off an engineering drawing. It was actually a great job, out in the middle of nowhere in southern Arizona at Ft. Huachuca and out of the rat race of California.
Our system used a largish VAX 11/780 computer that took up an entire back room in an old WWII army barracks. It ran four CAD workstations with the army engineers sitting at them designing communication relay stations. I used one of the workstations to develop custom applications tied to our über object-oriented database. The army engineers were civil servants, government employees, most of whom had been in the army. They were largely an interesting and eclectic bunch; one had been a tank driver, another a supply sergeant, and another a grunt in Vietnam.
Paul was the Branch Chief; he’d been a Special Forces/Green Beret in Vietnam and after the war became an antenna engineer. He was a sharp guy with some interesting stories who you didn’t want to cross. I’d been there a few months when Paul walked in and gave one of the army engineers (I’ll call him Norm) a printout of about 12 pages of Basic code. The Chief said, “Norm, this is a calendar and scheduling program I use on my Commodore 64 (I did mention this was 1984), I’d like you to convert it to run on the VAX, I’ll give you a few days. Let me know if you have any problems.”
Now Norm had never struck me as the sharpest knife in the chandelier; he had a passel of kids so he was a good breeder and other than insuring his legacy in the gene pool he seemed singularly lacking in viable skills. I was interested to see what he would do with the assignment. I’d been using C and LISP on the VAX but not the Basic.
Norm puzzled over the code for three or four days and then came up to me, pointed to the original printout and asked, “Do you know what this one function does? It’s not in the VAX Basic reference manual.” I looked at it and said, “I don’t. I haven’t used the VAX Basic or the Commodore Basic.” He then said, “I don’t know what to do. It doesn’t work without that function.” I said, “Norm, if I were you I would go into town at lunch and buy the Commodore 64 Basic book. It will have all the functions listed and what they do. Then you can find the analogous function on the VAX and get it working. It should be pretty straightforward.”
Norm looked at me like I had lost my mind, “That would cost me like $8, I can’t do that!” “Why not?” I asked. “There is no budget for it.” He said. “I’d have to pay for it and it’s work related. I’d have to pay for it.” By now I was getting the idea that greasing the wheels of progress with his own money would never intersect Norm’s reality. I probed a little, “Is there any petty cash fund around that you could raid for $8? Could you ask Paul to let you expense it?”
At this point I was actually getting hooked on the exchange, I had heard about people who clearly defined outlying work obligations as not their job. This was the first time I had seen such a blatant example of it in practice. I was wondering how it would unfold.
Norm, “No, no petty cash, I could raid the coffee fund but that would get me in trouble. I don’t want to ask Paul because he might wonder why I need it.” Ok, I thought to myself, there is a good reason to avoid asking for help. So I said, “Sorry Norm, I don’t know what that function does and I don’t know of any other way to figure it out.”
Norm shuffled back to his desk and proceeded to fruitlessly ponder the mysterious function for another five days. Finally Paul came in one morning and said, “Norm, have you gotten it converted yet?” When Norm mumbled a reply to the negative, Paul said, “Never mind, I’ve got something else for you to do. I’ll have Dwayne look at the schedule code.”
That morning Norm grudgingly gave the project to Dwayne. Dwayne was on the other end of the bell curve from Norm; he was a self-starter who took an interest in the world around him. Toward mid-morning Dwayne walked up to me and asked, “Don, do you know what this function does? It’s not in the VAX Basic manual.” Déjà vu. Keeping a poker face I looked at the code and said, “I don’t know, like you say, it’s not in the VAX Basic.” “Hmm” Said Dwayne, “Any ideas?”
I answered, “Well you could go into town at lunch and buy the Commodore 64 Basic book. It will have all the functions listed.” Dwayne brightened at this, looked at his watch and said, “That’s a good idea, I’ll do it. Thanks!”
Dwayne came back from lunch with the book, figured out what the function did, and had the schedule application running by mid-afternoon. Paul was happy and Norm was oblivious to the fact that Dwayne had, without even trying, totally skunked him.
Productivity, especially in the arena of programming, is difficult to measure, but you know it when you see it. The government paid Norm and Dwayne the same amount of money for their time. Norm spent almost two weeks to fail at something it took Dwayne six hours to complete. It was a very small project that mostly consisted of typing 12 pages of code into another system and testing it. There was one crux point and the programmer’s response to that point determined success.
For some people there is no stone too small to get in the way of forward progress. Norm was one of these people. He was unwilling to invest $8 of his own money or ask his manager. Not only was Norm cheap, but he was a bad communicator, who had existed for years by keeping a low profile. He seemed to believe that getting over being stuck was not his problem to solve. So instead, his manager needed to notice the lack of progress before he could take action. Norm certainly wasn’t going to mention it.
I still sometimes think about Norm, Dwayne, and Paul. The lesson for me is not about civil servants, it is about commitment and being invested in the success of the collective organization.
As a manager you want people to solve problems and escalate issues. The goal is forward progress. Like I stated at the beginning, I need a good interview question to verify the existence of creativity in a potential candidate. There are some common ones floating around but I’d like something unique that that instead of testing for genius, it identifies curiosity, flexibility, and even eagerness.
Monday, February 12, 2007
No Stone Too Small to Stumble Over
Labels:
coworkers,
creativity,
eagerness,
effort,
interest,
interview,
management,
motivation,
programming
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment