Connecting to LinkedIn...

A Day in the Life of a Production Support Analyst


Posted on 22/06/2015 by

Ugonna works in Production Support within the IPED Technology team. IPED stands for Investor Products and Equity Derivatives. Various applications and systems are used in the trading processes of these products and Ugonna provides technology support to global users in the bank. There is 24-hour support available and the London team which Ugonna belongs to works with users between 7am and 7pm; they have a weekly rota for either 7am-3pm or 11am-7pm cover. We asked Ugonna to give us an insight to a typical day in Production Support.


5am – An ungodly hour to wake up, but it has to be done. I fight open my heavy eyelids and scroll through the BBC news app. Greece this, Greece that. Yada yada.

6am – I guess it’s nice to avoid the rush hour traffic at this time and I’m guaranteed a seat. I sometimes check my e-mail on the way to work if my train ride seems to feel particularly long, but it’s not vital that I do, as I most likely need the infrastructure on my computer at work to act on e-mails. I read some Guardian articles and do a bit of people-watching.

7am – Time to log on to group chat channels and post ‘London Support online’ to let the global users and other support teams around the bank know that I can be of assistance to their queries. I scoff back some fruit and go through my emails.

7:30am – I notice a few jobs which have been sending out automated failure alerts every 15 minutes since 5:30am. Time to investigate and act quickly. It’s important to make sure these jobs are fixed and under control as a job failure could affect several users around the bank. A failed job could mean that a file containing vital information required by a trader is delayed in being sent out or that a risk check cannot be carried out because it is being blocked by another process. I look into some files and also use SQL to query the database. Job failures resolved.

8am – Continue checking through e-mails. Most are overnight updates, daily reports, system statuses and risk checks. I follow up e-mails from the day before. This is usually either me chasing people for sign-off or asking for clarification from a user about their query. It’s often the case that the user isn’t quite sure how to phrase their question or that they are not so confident with technology, so I make sure I come across as approachable and ask the right questions. I need the correct information to solve the query in the most efficient way.

8:45am – First user query on the chat channel about details in a report file sent out via a job. It has certain information in it which he wasn't expecting and suspects the job is faulty. I acknowledge his query and assure him that I am looking into it.

9:20am – Time for my packed brekky! When you start work at 7am, it’s almost pointless to eat before leaving home, so I wait it out a few hours before my power breakfast.

9:30am – My manager arrives and I brief him on what has happened so far in the morning. He tends to like hearing what the bottom line is, so no need for fluff. He gives me some advice on how to tackle the first query I received.

10am – I’m anxiously waiting for a response from a user I e-mailed last night. I need his approval in this e-mail by 11am in order to go ahead with an important change release he requested which needs to be done today. It seems like he was busy yesterday and this morning. Hopefully he doesn’t have a one hour meeting. Pretty much every change we make needs sign-off in order to have a clearly documented trail for audit. There are serious consequences if we don’t follow the simple but strict process.

11am – Luckily the sign-off I was waiting for came through just in time. I chase for three more separate approvals - one from my manager's manager - and then go ahead with the release. It goes successfully so I close its status and breathe. My manager comes back from a meeting, asks me how the release went and checks over what I did - he seems happy with my competence.

11:30am – 12pm – More user queries coming through. When this happens, it’s important to acknowledge each user as soon as possible but I prioritise my tasks to avoid darting between unresolved queries like a headless chicken and delaying all users.

1:30pm – Time for lunch and I’m ravenous. There’s actually a group lunch today with the other MThree alumni at a burger place nearby. It started at 1pm but I’m pretty busy today so can’t make it. Desk lunch it is. I ask one of my colleagues to monitor the support channels for five minutes whilst I befriend the microwave.

2pm – Support team meeting. We talked about upcoming events in the bank which could affect our team and what each of us has been busy with this week. I send out the meeting minutes to the team after checking them through with my manager and I am confident from this that everyone is now on the same page if they were not before.

2:30pm – I work through the rest of the queries from the chat channel and stay in constant communication with the users on the other end. It's great to hear pretty much immediately that your query is being looked into, but it's unsettling to not hear anything again for hours, so I usually send them a quick update on the status of their query or a 'please bear with me on your query'. The time taken to solve a query mostly depends on the complexity of the SQL you produce and sometimes on the layers of obstacles and red herrings en route to finding out what the actual issue is.

3pm – I don't like clocking off on the dot so I begin to wrap up my query resolutions and make sure my colleague on the late cover is aware of any that are urgent or unresolved. I brief my manager on what I've worked on today and discuss my plans for the next day with him. Even if I have already solved a query, he is great at providing input and explaining how he would approach an issue.

4pm – Leave work. Gym time!

comments powered by Disqus