I’ve had a number of people over the last few days ask me “How’s it going?” Only it’s not the greeting, it’s the polite way of saying “you look like crap — what’s bugging you?” (And you thought Santa’s “Naughty” list was long!)
I suspect the answer is process. You take a bunch of smart guys, throw them in a room, and the build something great. You ask them how they did it, and they tell all the “best practices” they used to get there. Formalize those steps, and now you got a process. Find a publisher, and now you got a book. And, just because it’s in a book, people think it’s fact. Remember when if it came out of a dot matrix computer, with rip-off-holes along the sides, it had to be true, because a computer said so?
Here’s the problem with process. It takes group functionality and lowers it to the lowest common denominator. It is predicated on the assumption that while people vary in skill, performance, and motivation, if you give them the same set of instructions, they can all produce masterpieces. What makes a monkey into a brain surgeon in corporate eyes? Process.
I view process as a laundry list of things you want to do, usually in a certain order, to make sure that nothing got overlooked or omitted. It is a wonderful sanity check, but it isn’t a substitute for talent, skill, education, and experience. When one abstracts away the details of a problem, process looks like the magic wand that makes it all come together. Of course things look better when you ignore the details; gheez — this is the only way some friendships can survive.
Instead, I argue that it’s knowing how to deal with unforeseen circumstances and getting through them in an elegant way that is where the real magic is made. You can bet that the Apollo 13 emergency return trip’s oxygen scrubber, built in just one hour out of plastic bags, three thumbtacks, cardboard from an instruction manual, the head of a used sock-puppet, a lunar suit, ten rolls of duct tape, and a discarded AOL marketing CD (1000 free hours) wasn’t conceived by some Ph.D. laced MIT process.
It’s over generalizations about what other’s do that get corporations into trouble. Here’s the latest in terms you’ll easily get.
- My Boss: Walt, do you understand spoken Spanish?
Me: Proficiently.My Boss to the Client: We have a translator on staff.
Client to Me: Write me a legal document in Chinese.
Me: I don’t speak Chinese.
Client: I thought you said you were a translator.
Me: I only speak some Spanish.
Client: Spanish is a language?
Me: Yes!
Client: Well, so is Chinese – do your job and translate.
Me: What’s the document supposed to say?
Client: Legal stuff.
Me: I’m gonna need details.
Client: I gave them to you: I want a legal document in Chinese.
Me: You do know I’m not a lawyer, nor a mind reader.
Client to My Boss: Your translator isn’t very good.
My Boss: Odd, he comes highly recommended. What’s wrong?
Client: Your translator says he can’t get me what I want by this Friday.
My Boss, looking at his watch: You do know today is Thursday, and he just got this assignment an hour ago?
Client: So you concur?
My Boss: Just for curiosity’s sake, when did you get this assignment from your superiors?
Client: Hmm, maybe four months ago.
My Boss: And you didn’t come to us sooner?
Client: It wasn’t a problem back then, we had plenty of time.
Change spoken language to programming language, broaden the time span, and remove the personified talking cartoon animals to do the conversion. But you see the essence of the problem — when you take someone who’s very specific and generalize their job, you cannot instantly assume they are a master of every derived subject area. Nor, might I add, does their knowledge suddenly expand to other fields of domain knowledge. Also, hiring an expert doesn’t give you time compression.
Do any of you non-programmers face similar challenges, and by challenges I of course mean friggin’ idiocy, in your jobs based on the sole criteria that what you do is over generalized?