jump to navigation

Friday Philosophy – On “Being the Expert” September 4, 2015

Posted by mwidlake in contracting, Friday Philosophy, performance.
Tags: , ,
trackback

Working as a recognised expert at something is a little…strange, I find.

I had an assignment this week to go visit a client, have a look at a performance issue and find out the root cause. I was also to at least come up with suggested resolutions with the ideal aim of giving them a proven fix they could implement. All to be done in two to three days. This is pretty standard fayre when you are putting yourself forward as some sort of expert in something. And it is not always an easy thing to do – for more reasons than you might expect.

When it comes to the core service you are providing you are certainly expected to know your stuff and if you are there as the expert and you don’t? Well, any pain you now suffer is self-inflicted so I have no sympathy. You might think actually being an expert is the hard part – the knowing all that stuff, remembering it, the ability to answer all the questions or look at an issue and in 5 minutes say “It’s because the CLOB settings are wrong”. ie matching the expectations of almost God-like knowledge and ability. But it is not. If you can listen to what their problem is, understand it and then explain something to them that they did not know before, it will be fine. What the client needs is to feel progress is being made. An immediate and inspired solution may occasionally be possible but on the occasions I have pulled that off, the client usually just feels uncomfortable, like they missed the obvious. Because they did. If I sort out the issue straight away that they have had for 3 weeks and that the in-house expert has looked at there is only really two possible reasons
(a) it is simple and they missed it.
(b) they ignored their expert.

The option of (c) my genius is sadly just a dream.

What I find more tricky is when they just accept what I say, when they treat everything I say as correct. Even if I say “it might be this” there can be an assumption I am being modest and it really is what I suggest. I’d like them to only believe me once there is some proof. Most of my time on such assignments is me sat at the SQL prompt trying to back up what I think is the issue/solution. Even when I have evidence, I know I could just be seeing what I want to see. I want some proof and I want them to challenge it.

There is also sometimes a tendency for the rest of the staff to regarded you as some sort of a weirdo, someone Not Like Them. After all, if you are an expert in Oracle Performance you must spend all your time looking at explain plans and 10046 traces and not doing normal people stuff. I have to say, I had a really nice (and in some ways quite worrying) complement a few years back. I was at a client site for a couple of months, plowing though what seemed like endless layers of bad code/design/decisions to make things run better. One lunch time I headed out to find some lunch with a couple of the developers. One of them turned to me and said something like “You know, I’m really glad you joined us. You’re just a normal bloke and not one of those freaky tuning experts!” He really thought all Oracle Performance people would be strange – and strange in the already bizarre context of all the other people that inhabit our profession. I wonder who else he had met?

You can also run into resentment – occasionally irrationally (fear of challenge? envy? just psychotic people?) but also for real reasons. I sort-of alluded to it earlier. You get listened to when you are “Being the Expert”. Even though you may say what Sarah had already pointed out last month, you get listened to. Sarah is not going to be happy about that. Sarah is going to be especially annoyed and resentful if she told Me, the expert, about the point I raised. In these situations I try and emulate what a friend of mine taught me about 10 years ago on “Being The Expert”. One of your jobs as an external consultant should be to tell the client to listen to their staff if their staff are getting things right. What the real problem is could well be that the client is not using the resources it already has. And you were, after all, hired to solve their problem.

The final thing I find strange that I’ll mention is this. As the expert I am constantly anxious I am going to be “found out”. I mean, right now, I am doing my final report on this assignment. I know I identified several issues, I backed them up with evidence, I moved the client forward. I found out things that they had not known. I taught some of the staff new stuff. I stressed that I will not have found everything as it was only 3 days with no access to the live system… But I worry that in 3 weeks I’ll hear that none of what I suggested worked and that the REAL issue was something I utterly missed and when they corrected that, the run time went down by a factor of a thousand. And I failed them.

I just worry about that. Because I am “Being the Expert”

Advertisements

Comments»

1. nlitchfield - September 4, 2015

I’d be astonished if in 3 weeks they’ve implemented any of your suggestions anywhere (unless it was a fire drill in which case they probably made technical changes without reading anything else and straight in prod). My ‘best’ experience a client buying faster hardware rather than change the row by row to a set update. They then complained to my boss that I’d suggested a code issue with their great code whilst all the time it was a hardware problem.

mwidlake - September 4, 2015

“They then complained to my boss that Iā€™d suggested a code issue with their great code whilst all the time it was a hardware problem” – That’s wonderful! Both funny and tragic at the same time.
You could well be right about the implementation. I will be pleasantly surprised if they put in place anything but the sticking-plaster fix, but then I know the chap I was working with is already trying to test the sticking plaster in their dev environment, so you never know!

One of my best failure-to-implement situations was when I not only gave a client a new partitioning strategy but also the the code to generate new partitions with stats and all the bells – AND I gave them code to automate it.
So of course for 3 months they rang me in a panic in the last day of each month for me to throw a new partition. “You have the code!” We have not looked at it “I gave you stuff to automate it!!!!” did you? Sorry, we will check it. I only threw one partition each month to “encourage” them to implement the code. Naive me. I should add that the last request to me was after I had left…
12 months later… Yeah, no progress.
24 months later….. He who came after me told me they had finally agreed to implement the automation IF an only after he added archiving.
Correct, Archiving was already built in to what I had given them, fully documented.
That’s why I retired šŸ™‚

Andy - September 5, 2015

Everybody loves hardware upgrade! šŸ˜€

I always tell my students that, hardware upgrades should be at the bottom of the performance troubleshooting recommendation list, unless they intend to start a career as a hardlware sales person :p


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: