Since my fist blog in February I’ve been mulling over creating my second, considering various different topics I could write about. I came to the conclusion to open the doors to my actual day job by creating a ‘Day in the life of’ post. Let me explain the rationale behind this decision – IBM’s a great company, and one of the things I think makes it great are the endless job roles and career paths available. Highlighting this is the fact that ever since I started at IBM, I’ve spoken to so many people (be it Apprentices, Graduates or regular employees) and I’ve never met two people who do exactly the same job. Ok, so that may sound like an exaggeration but, even if people have been doing the same role, it’s always been for a different client, in a different location or had some other variation making it unique. Now whether this is actually the case, or merely my experience being relatively new, we shall see, but one thing for sure: IBM’s got opportunities. Now I’ve digressed slightly, but I thought it was an important point to make. So back to why this influenced me to describe my daily role. This uniqueness, often for me at least, causes a slight haze over what people do; what does Technical Consultant or Test Analyst actually equate to on a day-to-day basis? As such, I thought it interesting to explore my first role in “Application Support and Configuration”.
So my role… since I joined IBM in February 2015 I have been part of a small 3rd line team who support and develop a business critical work flow application. Now I feel the key point in my description there is “small”, the reason I highlight this factor is because this is what has made my role so varied – with few resources available everyone pitches into most different aspects. First though let’s go through what I would consider my “core responsibilities”. My days generally start the same, checking access requests and doing proactive maintenance of the application and its surrounding infrastructure. This sounds mundane and don’t get me wrong it often can be, however it’s the “bread and butter” of the service my team offers, and by working in a proactive manner it ensures a good experience for the client. I then move on to dealing with incidents. When the client raises an issue with the application it gets assigned to our team for investigation. Resolving these issues entails contacting users, carrying out Route Cause Analysis of issues and occasionally creating problem and change records. Truthfully this is what takes up most of my time, as well as being the part of the role that can be challenging and by the same token incredibly rewarding. These incidents vary from single user problems to large scale high priority issues – single user problems are unsurprisingly what we deal with mostly and again can be very interesting. However for me where it really gets interesting is in high priority issues. The Service Level Agreements on these can be tight, and upon one arriving it’s a drop everything kind of scenario. Although these can be stressful, I’ve found I learn incredible amounts in very small spaces of time by just getting involved – I also always seem to come out of these with a genuine enthusiasm to find out even more, and the day flies by!
Moving on to my other responsibilities – this is where the “configuration” aspect of my job role comes in. Within the team we not only support but also develop the application and, as such, I frequently get involved with different aspects of this. Generally it starts with the client raising requirements for changes they would like. As a team we then analyse these and pass back a solution. From here the build begins, starting with development work in most cases, and this is the one aspect of the team I have not got involved in due to having specific people dedicated to the role. As such my input begins with the configuration of the front end of the application, by creating flows and inputting information to support the build etc. Onwards from here, I then get involved with raising the necessary change requests to progress the builds through from Development environments into Production. Whilst this is not the most stimulating job, for me it really cements my understanding of the changes when I have to explain and document them. As well as this, it really imprints the importance of change processes and procedures – a bit of a necessary evil shall we say.
So in a nutshell that’s my role, although there are other bits and pieces I do, there’s certainly not enough space to list them all out! I’ve enjoyed this role immensely, as it has brought me on in virtually every aspect – from presenting to problem solving, it’s had snippets of everything. I’ve developed a small amount of understanding in all these different areas, and it’s this attribute that I feel has made it the perfect first position. In turn, this has allowed me to understand what I like and what I’m not so keen on, which is invaluable considering I came into IBM with very little specific direction. Despite enjoying this role, I have now come to a point where for personal development, I want to move on to something new, and with my new-found understanding for my likes and dislikes, this decision has been made much easier! As such, I am now moving into a “Service Management Consultancy” role – a more hazy job description than “Application Support and Configuration” that’s for sure, but let’s save that explanation for another day, when I’ve explored it more myself perhaps!