You might have found me and my YouTube channel through this video.

And if you’ve followed me along my career journey over the last year, you’ll know I recently moved into a totally new role in the deep dark hole of consulting. Specifically, technology consulting.

I had to prepare for a few interviews about this role and understand what consulting really meant and I discovered that consulting is just this huge ginormous umbrella that covers a lot of different careers. The more people I asked for advice, the more careers I uncovered. Which lead me to finally realising what exactly the job I was interviewing for, was.

High level role background

It’s a role in the ideation, development and delivery of an intangible product. So on a very high level, sort of like a website, app, or feature of a website or app.

I am currently working in the consulting side of tech: this means that companies will come to my firm and use us to consult on ideating, developing and/or delivering the intangible product. So I’m not really helping out my firm to make or deliver stuff, I’m doing it for clients. This means that the products I work on could be vastly different – from public sector to financial services.

In a tech consulting team, you’ll normally have a team that looks like this:

My specific role is a business analyst. Because my current project’s team is quite a technical one, based on Scrum, and the project I’m on is quite large, the product managers on my side sit in an entirely different team, as do the people who manage and navigate the delivery of products.

There are also a couple of BAs on my team, which means that one is more responsible for being a scrum master while I take more of a hold on writing up tickets, managing the product backlog and navigating communications between all the stakeholders involved in a specific development phase.

So a tech consultant could fall under any of these roles, and in fact many other ones too.

Tech consulting; as a way for businesses to design & implement tech, encompasses a really wide range of careers. I’m a little more technical right now but there are teams more involved in the design of products, in the transformation of an existing digital service, in the digital strategy for a client to innovate, in implementing a product to help a client increase their revenue…. the list goes on.

Daily tasks

Daily tasks for me include managing the ‘product backlog’. In software development, you work with software such as Jira. It’s similar to creating notes on your iPhone except with much more specific detail for each note.

In your BA role here, you manage this list of ‘notes’, called tickets, in Jira—to make sure that each is progressing in line with the a) schedule for your current project and b) the capacity of your team. Essentially, making sure that each BA has a ticket to analyse, each developer has a ticket to work with, and each tester has something to test.

In line with managing the backlog, it’s making sure that everyone on the team knows what they’re doing in terms of the ticket detail. This means working effectively with pretty technical members of the team (developers, solution architects) as well as other BAs and product owners.

You will be having a lot of conversations with relevant stakeholders (either product subject matter experts—SMEs—or client-side product owners) about the problems you’re solving.

Consultants just think of solutions to business problems, right?

This is such a vague, consulting-based phrase but as a BA, you’re trying to identify the true business problem to figure out how to solve it.

The business problem is often delegated by the whole objective of your relationship with the client and why you’re working together in the first place.

So as a technical BA, I may be trying to figure out the problem with the system architecture or find the system-based answer for that.

For example, the problem we uncovered might be something we realised is necessary to work on, in order to get the client their end goal.

This means talking things through with developers and other solution architects and sometimes just doing desktop research. So an understanding of the right systems, maybe even the right coding languages can be super helpful here, but it’s definitely not necessary.

Really good communication skills is like gold dust in this role. Being able to have productive conversations, build good rapport with people and asking the right questions in the right way is literally the only way to get things done.

You speak to people in very, very, very different roles all day—from client-side to internally. Being able to manage these conversations, and make them productive, is an essential skill and is definitely part of your daily activities.

Keep an eye out to see if this changes in a year as the consultant hat really is a magic hat, and I’d love to work in a different phase of the product lifecycle during my career!