Isn’t it funny how our ambitions change over time? When I started IBM the possibility of ever performing a technical role seemed more than unlikely. So how did I end up getting into infrastructure and networking you ask? In all honesty I’m not too sure myself. No one in a business orientated role wakes up one day and decides: ‘actually I want to become a network engineer’ – it’s simply not a natural thought process.
When I started on my first change management role I had very little Idea what delivering an IT service really was and what delivering it actually involved. As a change analyst in my first role I began to read change request and get to grips with what technicians would actually be doing – this is where my interest in networks began. Being a fairly visual person I was attracted by the topologies and the logic behind how routing and firewalls worked.
While using TAD4D discovery tool (an IBM software discovery tool) I started to use some command lines in AIX and Linux. As childish as it sounds I thought it was out of The Matrix and my curiosity for what was possible grew. Coupling this curiosity for the logic and the novelty of the command line I became quite enthused about this area.
It’s normal for IBM apprentices to move roles every 6 months to a year so as I approached the end of my time in Asset and License management I decided it was time to vamp up my technical knowledge and take on a challenge in the accounts infrastructure team as a network engineer!
So around 2 months in to the role, what tips can I give to anyone else who may also be taking the leap or thinking about becoming more technically orientated? Here are my top 4 lessons so far
I’ll take that VLAN and DHCP it where the OSPF doesn’t shine.
There’s no simple way to get up to speed on the jargon other than to get on Wikipedia and read. If you need to use it in your day to day role you will naturally develop a deeper knowledge of what you’re talking about. I find keeping your own dictionary of terms is useful (as writing it out helps to remember).
Suddenly hundreds of small and big tasks are thrown your way so how to prioritise?
Let people know what else is on your plate. It sounds simple but often people want things done now but sometimes they realise they can wait when other work takes precedence. Talking them through what else you have on ensures you don’t appear work shy when you say you aren’t able to deliver within the wanted timescale.
3) Negotiating a multi-vendor service
Ooo doesn’t that sound fancy! It just means we are using hardware from many different suppliers all with different command lines and GUI’s which can sometimes leave your brain in a mush.
Make sure you always know what the help command is: normally a ‘?’
4) The Banter
As someone who’s learning the ropes and is building their knowledge mistakes are bound to occur. But the banter that follows sometimes goes way over my head. (For example a colleague described the problem as being a layer 8 issue…. After a quick google I think he means me the user)
My advice here is to keep your cool and learn from it. Try not to worry, if your manager is any good he won’t let you run before you can walk although it might feel like that sometimes! And take part! (When appropriate: don’t make jokes of a service outage for example).
Well I hope this has been a useful insight. Overall I hope what this demonstrates about the apprenticeship is the diversity of roles you can get into and the level of support IBM is providing us to do so.