My Geeky Dream (one of a few!)

Many years ago I when I was working as a support engineer for a managed services company I had the pleasure to be assigned to a company as a temporary tech support resource. Nothing major in the way of technologies and such. Just your standard support for Windows for Workgroups (yes I am not a young man any more!).

I was lucky enough to be allowed to look at this companies server room in their data centre. The one thing that really struck me was how well organised it was. Tidy cables, clean floors, space not being used for storage and the other nightmare's I have encountered in the years since.

Speaking to the manager who ran the centre I found that his secret was organisation. As an example regarding cabling -

All Red Cables - WAN
All Green Cables - Server Backplane to server switch
All Grey Cables - Patch Panels to desktop
All Yellow Cables - Print Services

And so on.

The reasoning was simple - it reduces confusion and is an indicator of the relative sensitivity of the kit the cables are connected to.

I thought back then (and I still think) that this is a great way to keep organised. Sure you have your systems labelled. Usually at the front though. When you are behind the server rack and working on equipment you might not be aware of what is connected to what.

Its all about risk mitigation isn't it?

So on that note I wish everyone a prosperous Happy New Year!

Something are just not worth releasing

I am a bit of a fan of film. If I had seen this either in the cinema or on television I am not really sure of my reaction beyond sheer horror!

Video is via this link (youtube).

This is possibly the worst example of modern special effects I have seen to date.

I think I would not be able to show my face to my peers if I did something like this in my profession.

Communicate! For the Love of Sales Communicate!

Imagine.

You are pitching for a multi million dollor/pound/euro deal. You are in the boardroom of your customer. The CEO, CFO and various other boardmembers are in attendance.

You turn on your laptop to start your presentation. You insert your tumbdrive with the presentation on it.

Access denied.

I have to admit to being thankfull that it was not me in that situation.

Unfortunately I took the call from the poor bugger though.

That morning I had been politely informed from the corporate security team that a new security tool had already been pushed to all laptops which locked down functionality in terms of USB/CD-ROM/DVD access.

Salesguy had been in the office and logged on and had the tool had been pushed to his laptop before he went to the customers site.

Bad timing.

So along with this persons issue I had calls that swamped my service desk from all sorts of people who needed access to these devices due to their work.

A simple matter of communication letting us know that this was happening would not have resulted in the loss of a rather large sale.

Using the principles of Release and Change Management would certainly assist in reducing these issues. Needless to say the actual tool was buggy and we had an awful lot of work that needed to be done to recover. Luckily I had a great ICT support team and we managed to get through the issue but not without an awful lot of pain. I mean A LOT OF PAIN.

Its not fun getting chewed out for something that you had no idea about and little to no control over.

Communication is vital.

Hello? Anyone There? We Heard There Was A Riot!

How to deal with the unexpected.

We get a trouble ticket stating that a remote site in a third world country had no network connectivity. This was reported to us from an automated system rather than a human.

So we start the usual investigations - ping and trace routes.

Always timed out with the last hop being a local ISP. Very odd.

We tried to get in touch with relevant persons on site and at the ISP. Absolutely no joy. What could we do but wait for someone to arrive on site and contact us (we left numerous messages and emails).

During our lunch break one of the lads working with me had a news aggregator and the city where our site was located appeared. Large scale riots reported.

Madness, Mayhem & Anarchy apparantly.

So we knew that it was going to be a very long day waiting for someone to arrive on site. Eventually (I think possibly the following morning) we get a message from the site manager.

"Unable to log on to network, office broken into and damaged"

We then activate our local external engineer who arrives on site and calls us back.

Engineer "I found the problem, the network is gone"

Me "Ok...just reboot the switches and servers and lets see where we are"

Engineer "That could be a problem"

Me "?"

Engineer "Well...unless we can get data across two tins cans a long length of string I am going to need alot of CAT5"

Me "?"

Engineer "Yes...the robbers took all the copper cabling from the building"

Me "!"

Sometimes....things happen you have no control over.

Dr No's Secret Lair!

I have worked in many different places and environments but this...this is awesome.

Link to the Lair of Dr No.

Yes. I want one. I don't know what I would do with one (well actually I do but for the sake of a cheap joke lets ignore this part) if I had one. Maybe take over the world ala Pinky and the Brain?

Jokes aside I wonder how many other shelters are available and in a position to be build out as data centres. Certainly this facility would have many inherent advantages for high availability data centres that you would not find elsewhere. One downside I can think of is the usual remoteness of these places.

I would also find it hard to resist to play the role of Q in such a place!

Help! I Need Somebody!

Apologies for the lack of posts recently. I have been interviewing and researching for upcoming interviews.

Which (oddly enough!) leads me to a story when I was a manager hiring a new support engineer. I am a pretty plain speaking kind of guy and when I interview potential new team members I make it clear what the work is like.

When working in support you need the right kind of people who can handle dealing with problems and dealing with people with problems on a constant basis and still be professional and pleasant. Its not easy and not for everyone. You need the technical skills, the ability to communicate with non technical people and of course able to deal with stress. I prefer good humour to combat stress but of course tech humour can be quite dark. I think spending most of your working life dealing with problems lends itself to a certain jaundiced view of life.

So one of the things I make quite clear is the expectation of having to deal with stress and problems. How do you (as the candidate) deal with stress and the like.

Well I was interviewing one person who mentioned that while for the most part they are able to deal with stress they do have a breaking point and when that point is reached, chances are that this candidate will resort to some form of violence.

I don't think I have ever really been speechless before...Still on the plus side the direct questions seem to have uncovered this candidates violent tendencies.

Lessons learnt - when interviewing

• Be Honest
• Be Truthful
• Be Direct
• Set Expectations

I have found that following these four simple concepts I have managed to recruit some top notch support engineers during my career so far.

Be Honest - if its an intensive role and fraught with stress...tell the candidate. I'd rather have someone think about this and reject the role than join and find out 6 months down the line that the job is not for them.

Be Truthful - there is nothing actually wrong with admitting that there are problems as long as you are looking to correct them. In this case I would be truthful to the candidate and make clear what the candidate brings to the role and business as well as what challenges the candidate and team face.

Be Direct - too much time and effort is wasted with running around in circles. I much prefer to be direct and give concrete reasons or answers to candidate questions. The interview is not only for me as hiring manager to make sure a candidate is suitable but also for the candidate to acertain whether the role or the team is for them.

Set Expectations - This is really important as far as I am concerned. Of course this needs to be in line with the needs of the team and business which I think the vast majority of candidates understand. Especially in today's world of fluctuating economics. Having said that I do find that being able to tell, if not specifically then generally, what the expectations are from me (hiring manager/team manager) and the business.

I'm not a professional interviewer and I am sure that some of my techniques give professional interviewers the heebee jeebee's but I have had a reasonable success rate. I know team members I have recruited appreciate this.

Dammit Jim! I'm a Hardware Engineer not a miracle worker!

I really enjoy working with people from different cultures and countries. Not only does it widen my horizons but also affords the opportunity to meet new people with very different points of view.

However there are some truths that are universal.

I was dealing with a desktop machine that had lost its networking capability. A pretty easy fix...just need to install a new step card and install the drivers. This card was not on the NT4 HCL (hardware compatibility list) and therefore the device drivers had to be installed by hand.

As I was several thousands of miles distant from the machine I needed to engage with the local hardware engineers. So I call them and state what the issue was and what I needed to have done. Which was really to install the step card and put a floppy (install disk) in the disk drive.

They were more than happy to do the install. No problems. Until I came to the part about the floppy.

'Sorry but we are hardware engineers. We don't 'do' software'.

Picking myself up off the ground after hearing this, I replied that that was a very interesting answer and that while yes indeed they were hardware engineers driver installs are a part and parcel of the job.

Much too-ing and fro-ing ensued regarding this. The engineers were resolute that they should not be installing any software or middleware or any other kind of ware.

Eventually the end user herself installed the entire thing including drivers in about ten minutes.

Last I heard there were two hardware engineers looking for work. They did not realise that the machine they needed to fix was actually their bosses. Oppps!

Lessons learnt – well for the hardware engineers I'd say the top one is to find out who has a problem before playing games.