Recently someone close to me asked that I explain what exactly it is that I do at my job.

At first I was stunned by the question. How could someone who plays a key role in my life, not already know how I spend half my waking hours? Why hadn’t they asked years earlier? Do we all just spend our lives not really having a clue what everyone else around us is up to?

In the end I concluded I might as well write down my answer, perhaps someone else will find it useful one day.

# Senior Consultant

On my little business card it says “Philip Mallegol-Hansen, Senior Consultant”, though frankly I don’t find that description all that useful. First let’s break it down into it’s two terms.

## Senior

What does senior mean? It means there’s someone else whose job is “Consultant”, that person doesn’t get paid quite as much as I do, and presumably they’re slightly worse at their job than I am. I’m not really a fan of senior, it implies some kind of finality in my mind. If I’m the senior one, there’s no such thing as senior-senior right? Senior is the top of the pole? Wrong.

Senior is in fact second lowest on the list, second only to “consultant”, beyond “senior” there is “principal”¹, “senior principal”², “director”, and more. In the end “senior” isn’t much more than an indicator of how much I get paid relative to my colleagues.

## Consultant

Consultant then, what does that mean? Well… it’s complicated. First I should point out that there are many distinct areas of expertise in which one could be a consultant.

I find that most people assume a consultant is an MBA type whose purpose in life is to come into a company, help leadership cut the staff by 80%, and force the remaining 20% to do 120% of the work the team previously managed. Those people may absolutely exist, and it may even be true they represent a large proportion of all “Consultants” out there, but that isn’t me.

My area of expertise is broadly “Technology”, and more specifically I would describe it as: A deep understanding of the Agile, DevOps, and SRE movements, and how they help us develop better software - Particularly the backend server kind.

Alright that’s a lot of words, maybe it makes sense my business card doesn’t say “Senior Agile, DevOps, and SRE informed backend server software Consultant”, but it really does require that level of specificity to even get a hint of what I actually do.

With that idea of a slightly more exacting job title in hand, what does such a person actually do day-to-day? I would categorize these tasks in two distinct buckets. “The work” and “The work around the work”.

# The Work

9 AM, I have my coffee all ready to go, I roll into my home office and turn on the computer. What is my job again?

As a consultant, I’m a contractor. Meaning on paper I work full-time for my employer (Slalom), but the actual work I do isn’t for my employer, it’s for my client. Just like when you call the plumber and someone comes out to do work on your house, my client has contacted my employer to get me to “come out” and do some work for them.

The clients vary, they can be anything between large world-famous corporations, local governments, small local firms I haven’t even heard of myself, or something in between. The people I work with tend to be IT / Software Engineering organizations within those companies.

Depending on the particular project, that might look more like getting on a video call with one or more engineers, and coaching them through something they haven’t done before, or it might be creating PowerPoint slide shows to convince their managers (or their managers’ managers) that investing in your technology department is actually a good idea³.

I don’t get to spend all that much time deeply focusing on a problem like I used to as an engineer, I’m definitely living on the manager’s schedule most days. An average day seems to be some combination of writing small snippets of code to demonstrate a lesson, fighting organizational bureaucracy to gain the access I need to my client’s systems to actually execute on the work they’re paying for me to do⁴, creating slide decks, meeting with clients and colleagues, and handling project management systems.

# The Work Around The Work

The nature of consulting is such that at times I’m not working on a project for a client, but rather working on a task for my employer, generally in the pursuit of more contracts for us to work on in the future.

The work generally known as “pursuit” is a combination of:

• Posting stuff on LinkedIn that might entice potential clients to reach out to us, showing up at conferences, or local communities with the same purpose. That which is commonly known as “networking”.
• Meeting directly with potential clients to hear about what problem they are trying to solve, and believe we might be of assistance with.
• Writing business proposals based on the conversations above, and pitching potential clients on these proposals to win business.
• Assuming business is won, writing the contracts that more accurately and formally spell out what it is we are agreeing to do on behalf of our clients, and the compensation they will pay in return.

Besides the activities that can directly be seen as pursuit, there are a number of other activities that support our business less directly, like:

• Mentoring other consultants on the things I know, enabling them to take on new work in the future.
• Creating demo projects involving technologies or methodologies we don’t currently offer, as a jumping off point for others to (hopefully) see the promise in an offering I believe we should add to our toolbelt.
• Organizing team building activities - Given that we generally work with our clients on a daily basis, not the other consultants in our company, team building is particularly tricky in the consulting space.

# Conclusion

I could probably say a bunch more, but this is already getting long. I hope I’ve at least offered you a sliver of an idea of what a “Senior Consultant” with a focus on software development might do with his day.