I’ve been having a chat with a friend of mine who’s overseas; I thought I’d share a couple of things that came up.  (All I need now is comments facility on this blog so we can all chat about them [sigh].  It's coming).

"I don't think I want to stay in support roles forever.  What I really want to do is get an ITIL qualification and try for management jobs instead."

Deciding what you want to do is one of life’s great challenges; the challenge then is how to get there.  The approach I’ve taken to the first (and possibly the second) has been two-pronged:

• Pick a general direction, and go that way (but not with the absolute laser focus that some people have).
• Be prepared to take a risk / do something you hadn’t thought of when it's offered by fate / chance / luck.

It’s like the agile manifesto says: “Responding to change over following a plan”.

Interestingly - I remember a quote from a famous New York based (theatre) Lighting Designer, what he basically said was:

If you want to be lighting designer - then only accept lighting designer jobs.  Never accept or do any closely related jobs; what will happen is that although you'll get into the theatre scene - it will be doing something other than a lighting designer, and you'll build up a reputation for that - and not lighting design; you still won't be a lighting designer.  Take on any job you have to just to get money - as long as it isn't in theatre - even if it's just waiting on tables.

I think this is very good advice - a good strategy to keep in mind, but (and there is always a “but”) you have to take your context into consideration.  I think what he said was perfectly right - for New York; where there are many people, roles are highly specialized - because the local context was of a scale that not only supported that - but actually made it necessary. 

(In a former life) I did a variety of professional lighting work in Wellington, but Wellington is much smaller than New York; you can (or in a lot of cases you have to) do multiple roles because the local scene is small and can't support highly specialized roles (at least not to the same extent).  In this particular context knowing some people and being recognised (trusted) within theatre work (in general) can be enough to create lighting design opportunities - if that's what you wanted.

So ultimately – in my humble opinion:

• Pick a direction but be prepared for change;
• And, can you get there from where you are?

Next:

"I have so many ideas in development - around how to make my organization better.  For example, here I could make most of my colleagues look useless - just with some good scripts which could be developed in about 1 month - and which will include all the common procedures and metrics that they use.  But that's why some of my colleagues don't like me very much and I'm not into doing it of course because they realize that: 1 developer = 5 support specialist (or maybe more)  What do you think?"

Most people don't like change, and it's easy to make these people feel threatened when you suggest something which in their eyes is new and radical (even when you and I know it's trivial / common sense).
This is a big challenge we face in life, all the time.

Another way of looking at it is this: they do their job their way; people are happy (or appear to be).  Then you walk in with a script that does 10 times as much in half the time; of course this is going to make them look bad.  One possible  (and positive) approach is to try and get their involvement, so that your idea / success is somehow shared with them so that they don't look bad - everyone wins.  But - I'm not saying that it’s necessarily easy to do :)

I've recently read Seth Godins "Tribes" which has some excellent ideas.  One of the things he talks about is basically to encourage positive division:

• State what you're about.
• Attract like minded people.
• Let those who don't agree go their own course.

In some ways: "Lead, follow, or get out of the way".

Thinking about writing high performance scripts reminds me of a story.  A friend of mine told me about some consultancy he did once – he’s an absolute SQL guru; I guess the guys who did the original work must have been novices (not their fault) - here's what happened:

• They had query that took 20 minutes to run.
• My friend put on some indexes and got it down to 20 seconds.
• He then restructured how they were doing the query (I think he did some batching and so on), and got the execution time down to … 20 milliseconds (!)

20 minutes to 20 milliseconds.  OMG.  You can imagine what people must have been thinking.