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 -
Speed to Value
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
quicker to figure it out for yourself than to search for some other
have a ready answer. Bottom line is, the rate-determining factor is the
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
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
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
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
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 ...
, 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".
, 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
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
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.