From Algorithms to Invoice Approvals

I spent a lot of time studying hard in uni. Things like algorithms, data structures, operating systems, and software architecture took up a lot of my time. Occasionally at work I do tasks which deviate so far from what I learnt that I wonder how I ended up here. Don't get me wrong, I understand that part of an engineer is having great problem solving skills. But sometimes the problem is just something I never thought I would be solving. Here are some of these random things.

Becoming a finance expert

At my current job I assist with a lot of automation, particularly within the finance team. The first thing which I automated was invoice posting, which was relatively simple. It only became weird when I got dragged into a meeting and had to assist with manually drafting the invoice template. Someone mentioned that I had automated this and all of a sudden I became the "finance expert". It got worse when I absorbed some responsibilities of the finance administrator. Before I knew it I was doing things like invoice approval and management, procurement, and learning more about accounting terminology than I should. I got saved by a manager after a few months of doing this for the finance team. Truth be told it wasn't too bad, and in another life I may have been an accountant.

Marketing Automation

My team and I worked on a project to automate lead flow into a platform called Marketo. It was a simple cloud flow which made a call towards the end to their API. We got a lot of praise for this simple task, and then became known as the Marketo experts. It was flattering, and came with much more responsibility including creating fields in Marketo, lead generation issues, flows, and email delivery issues. I'm not sure how that happened. Somehow every marketing issue became a software engineering issue. One valuable thing this taught me though was that companies are willing to throw a tonne of money at useless programs which can be made internally for free.

Inheriting legacy systems

Sometimes there's integrations at work that no one touches for years, and suddenly break and cause issues. When you go to fix it, you realise the login details aren't stored anywhere in a password manager and you're forced to go back and forth with a rep. After fixing it you get a pat on the back, become the new owner, and inherit a system you didn't know existed three days earlier. This entire process happens a few times a year, but you get better at it each time.

SharePoint Development

If I heard the phrase "SharePoint development" 5 years ago I would've started laughing. Before I went into the workplace, SharePoint was a simple tool to store documents, but years later I was troubleshooting permissions, setting up document libraries, relying on version history and trying to work out where documents went missing. Document management became a big part of my day-to-day at one point. Like the other issues, this started out with completing a simple task and then being known as the expert. I wouldn't say this skill is entirely useless, but when requests come in to help restore documents from the recycle bin I question my career choice.

My take

I don't regret learning any of these things. Understanding finance, marketing platforms, legacy systems, and SharePoint has actually made me a better engineer. It also gave me a much better understanding of how different parts of a business actually operate.

That being said, there is a fine balance between being a friendly neighbourhood software engineer, and inheriting someone else's job. Sometimes the right answer isn't to take on more responsibility, but to make sure ownership sits with the right team. Otherwise, you'll wake up one day wondering why you're restoring SharePoint documents, troubleshooting marketing campaigns, or approving invoices.