Would you like me to google that for you?

Got some rare Re–Tweets today on a techie insult – so snappy, I had to write a post to use it for a title!

Deep in the problem analysis and debugging process, the typical IT hack experiences counter-balancing pressures that impact decision making – Capable Independence vs. Speed to Value.

Capable Independence is just fancy-talk for the idea that I should know what I’m doing.

• Ego 1 – Who needs manuals, I wrote this thing from the ground up?
• Ego 2 – Vendor support is useless, I teach them stuff whenever I call …
• Delusions of Center – I’ve been working on this ERP, for this company, for 15 years – I should know how this works!
• Paranoia – If I have to ask for help, they might think I’m not worth keeping around …
• Pride – I should be able to figure this out myself …

Actually, I think the truth is a bit more mundane; everybody is really busy, and it just seems quicker to figure it out for yourself than to search for some other resource, that might have a ready answer. Bottom line is, the rate-determining factor is the idea that I should be able to solve this problem – so the problem won’t get solved until I figure it out!

Speed to Value is the idea that I need to get an answer quickly – time is of the essence. Unfortunately, taking the “I can(must) do this myself” option may seem quicker, but in practice, folks will jump to what they know vs. really understanding the root issue – and (more often than not) come up with a less-than-optimal solution.

I want the optimal solution – quickly, but implemented with the least amount of effort, taking advantage of standard product functionality, and (therefore) easiest to support in the long run.

Know What You Don’t Know

One of my favorite war stories involves Amit, the brilliant (truly) analyst with 10+ years experience on our ERP, in multiple companies supporting multiple business models. He’s seen it all, right?

We were trying to send nightly extracts to a data warehouse, so I asked Amit if he could identify all records that had been changed in the last 5 days. Amit said No (almost immediately), and I was Skeptical (just as quickly). IMNSHO, most transaction systems mark records with something like a ModifiedDate field (one of my favorite triggers …), and I was assuming that our ERP, being a solid mid-tier platform with a long history and a lot of customers, would have also implemented this basic idea.

I knew Amit was super busy, and suspected he was answering off the top of his head – but I also knew him to be humble, open-minded, and down-to-earth  “Look,” I said, “I know you are a terrific programmer, with deep knowledge of the system, and I don’t want to insult you, but I am going to ask what seems to be a very basic question. I don’t mean to insult your capabilities, I just need you to answer very specifically …”

Do you

know categorically

that the system cannot do that,

or do you

not know how

to do that in the system,

or have you

never heard of that

being done with the system?

The answer-off-the-top-of-my-head is a way for me to quickly address a question just to get it out of my way. Sometimes “no” means “I don’t know how to do that, and I don’t have any time to research this”. I was pretty sure my good friend Amit was trying to slough off the question, because he was already working on 50 other things for me …

Irregardless, I asked Amit to take the time and research the question, because I was sure that any decent ERP would have this field. Next day, Amit came back to me in said “thanks for asking so specifically; I actually did not know if the system could do this, and so I did the research”. Unfortunately, he was right – lo and behold, the system did not have a LastModifiedDate in one of the tables I was looking for, so we had to hack and an alternative method.

But it was still worthwhile to ask the question.

Failing Faster, Getting Lazy

Why do we insist on solving problems ourselves, and limiting the solution set to what we know? Why can’t we let our self-directed searches fail fast enough to ask around for someone who might know more? Remember, your company is probably paying plenty for annual maintenance on the big software platforms – we all should [more quickly] be “giving up” and “failing”, submitting the question to the experts to quickly get some answers.

In an internal blog, someone posted a brutal techie diss – Would you like me to Google that for you? The source was frustrated that the rate-determining analysts weren’t even taking this basic step. My personal theory is that they’re not “lazy” enough – I’ve got many other things to do, so I want to find a quick way to answer those questions.

The business doesn’t care if we know the answers – we get credit for solving the problem!

ps. Note that “laziness” also makes me want to find a good solid solution and not a quick and dirty solution, because I don’t want to have to come back later – I’m proactively lazy.