Why write this blog and what makes a good consultant

When I started as a consultant I had no idea what the job would entail. I’m not really from a formal technical background. I’m part teacher, marketing manager and engineer by education. IT has always been sort of a hobby, where I’ve been working on coding, configuration and other solutions for a rather long time through either volunteering at local LANs, writing about IT in the school system and so on – but it was never what I made any money from. My mother said “work in IT holds no real future” when I was young, so I focused elsewhere.

I did after a while get a job as an internal corporate consultant for Lyse (a local Internet Service and Power Provider) and then as a consultant for a company called Upheads, where I was taken up as an IT consultant. I enjoy learning and find taking certifications a nice way to confirm my competency, which suited working in the fast moving IT sector.

Here’s where the blog comes in. When I started out as an IT consultant for Upheads, one of the worst things I had to do was to read tons and tons of technical information. Most technical documentation or courses are written by overly technical people, for other overly technical people.

What do I mean by this sentence?

When we read technical articles, we need to understand the history and the underlying components of the concepts we’re reading about. Reading about Single Sign On Authentication for instance requires you to understand how endpoints, active directory and processes like Windows Integrated Authentication, Basic authentication and Secure Authentication Markup Language works. When things are explained by an overly technical person, they tend to expect the reader to have the same foundational understanding as they do. This does not work, and makes IT a much harder sector to get into. It may sound obvious, but there is another layer to it as well:

What makes a good consultant?

I’ve said it a thousand times, and I’ll say it millions more. As a consultant, our job is 95% communication and 5% technical ability and know how. You may be the highest certified person on earth, but if you can not explain to a user why they should check where the link leads before pressing it – you’re useless in a consultant setting.

You will need to be patient, calm and handle stress well. Users have different focuses than you do, and will not necessarily understand why it’s so hard to get a system back up after an error, or how an update can crash a system. Patience will serve you well when you’re talking to non-technical personnel who believe they understand concepts and know them better than you do. You’ll need to understand everyone want their voice heard and filter out the information you need from the static.

An example of this was when I was the lead consultant at a company in the oil sector. We had this one representative from the company who constantly talked over everyone else, believing he understood the technology better than the hired in consultants. He made unscheduled changes without updating the design documents, added and removed policies and installed applications to the network without informing the technical staff. Eventually he removed the AD role from the singular Domain Controller server because he wanted to move the FSMO roles to different computer, but hadn’t done it according to the workflow – taking down the entire company in the process. Patience and foresight allowed us to see this happening and planning for the rollback that would inevitably happen.

About technobabble

Technobabble is defined like this:

I try as hard as I can to refrain form technobabble. A lot of IT people will use technobabble to hide their own incompetence and to explain technology as if it was magic. A type of technobabble is the three letter acronym. In IT (itself an acronym for Information Technologies) we love these acronyms. Take for instance the example above – I’ve not explained what the FSMO roles are, what it stands for or what they do. Writing things like this makes the information difficult to process for non-experienced staff, and makes it harder for non-technical users to understand what you’re trying to explain.

When talking about your job, even in social settings, what you do or explaining concepts to users: Refrain from using these acronyms, unless you’re explaining them as a pretext. You’ll see in my articles how I try to explain these concepts by drawing them or walking you through it before using the acronym itself.

Use real-world examples or parables to explain the concept instead when you’re talking to users, as they don’t have the same foundation of knowledge as you do.

About honesty

You’ll fuck up. I hate saying it, but we all do – and it’s one of the defining moments for you as an IT consultant. There are two schools of thought here:

White lies
Use “update” or a different event outside of your control to explain why things go wrong.

Be honest
Tell the truth – I fucked up, but I’ll fix it.

I have done many things wrong over my life. But I’ve come to experience being honest and clear on your intentions to be the saving grace for when things go wrong. This is especially important if you’re ever involved in an invoice dispute. Being honest about what happened, documenting your work properly and making certain everyone is involved in the communication flow will provide you with a lot of peace of mind in your cases and afterwards.

We had a consultant who was asked to change the memory chips from a server and proceeded to yank them out while the server was running. The system of cause immediately crashed, with no warning sent to users or processes saved. I was honest and informed the administration of what happened and how we would fix any issues following the incident for free. The incident ended up being a learning experience for the junior consultant, and allowed us to show the customer what kind of trust they could place in us.

On checking in

Customers will need you to check in. Do not under any circumstance believe silent customers to be happy customers. Silent customers are way more often just “maintaining” themselves, and considering newer impulses like different suppliers. Checking in on the customer when the environment is “fine” will give you a much better relationship than if your presence is the pretext of doom.

I’ve been there myself. I had a local school providing certification processes to oil-sector employees where the teachers retreated to their offices whenever they saw me, because I was never there when things were OK. Trust me, when several teachers fight to get to the printer because you walked through the doors, you’re the pretext of doom.

It’s similar with the C-Suite (CEO, COO, CTO and so on) leadership of the same customer. Whenever they saw me, all they saw was cost. This meant they hated talking to me because there was always an invoice at the end of the conversation.

People matter

Find yourself a supporter whenever you’re at a customer-site. It doesn’t really matter who they are or what they do, but having a person who speaks your case whenever users are annoyed with you will make all the difference. IT consultants can end up being the scapegoat for anything and everything. If something doesn’t work, a system is poorly designed or even when Microsoft is having issues – you’ll want a person in the organization who say: “He said it was Microsoft having issues” – “She’s working on it” – “It’s not his fault”.

Having a supporter will also help structuring requests. If you have someone in the organization who likes you, they will often become the person who can tell you who’s experiencing issues and who isn’t. As you’re not internal in the company, never under estimate how much users talk to each other about their annoyances. Their information or ticket may not reach you, but having a supporter will often show you where the real issues are hiding.

Consider this: How often do you speak your mind freely to your leader / supervisor or organization leadership in comparison to other users?

Consider as well how basic human decency helps make you more palatable to the organization. If you’re provided a cup of coffee for a meeting, put it back in the dishwasher. If you’re going for a cup of coffee yourself, ask the other participants of the meeting if they want one as well. Wash your hands after going to the toilet and maintain good personal hygiene is incredibly important. I can’t believe we still have to say this in 2022. This is from an anime convention, but is just as common in IT:

Being liked will mean people actually want to talk with you instead of yell at you. You don’t yell at a friend who’s made a mistake, but you absolutely will at a greasy carpenter who has knocked a hole in your wall after leaving you with a mess in the kitchen and an invoice.

Return on investment

You are a cost. You’ll always be a cost. An IT consultant will never make a good return on investment on it’s own. Your ROI (return on investment) should be quantifiable on either an “ease of use for users”, “cost saving on IT systems over time”, “organization process optimization” or “user process simplicity” -scale. You’ve probably seen this before:

And it’s fairly true.

When users are working and happy, you’ll quickly become simply a part of the background. It’s fine, that’s where you want to be. A working solution is a calm consultant and a happy leadership. If your presence can become synonymous with higher productivity and a better process for the employees – you know you’ve succeeded as a consultant.

This is partly why I always ask what a successful outcome of a project is to customers. Partly because it explains what the customer values, but in addition it’s a clear pointer of what the users require from the project and provides you with a clear end-goal.

Internal communication

When I was working as a teacher, we were taught about what the professor called “the account” -parable. When you have a positive communication or situation with the user, you put “value” into the account of that user. When you have a negative communication or situation with the user, you withdraw “value” from the account. When you have issues in the environment, your communication and the rate of information flow to the users will define how much value you take out or put into the account.

I had an incident with a customer where a company computer was “hacked” and crypto’d (cryptographically locked, leaving it unusable). Immediately, the computer was isolated by the antivirus package and the attack was contained. As soon as I received the case from our Service Desk, I sent an email out to the leadership of the company and informed them of the situation, how it was contained and how I’d be coming out to collect it. The computer was collected and a report was written explaining how the attack happened: It was an exposed RDP (Remote Desktop Protocol) connection and a local account from the initial computer setup with a simple password who was never removed. The computer was later reset and returned.

Before the situation happened, the customer had been threatening to leave the organization I was working for, but after having that comfortable experience where the leadership was constantly in the know and had full overview to the point they were able to answer their users on what was going on; they decided to keep us on.

On the topic of the Service Desk
When it comes to the Service Desk employees – please don’t call them names. They may not know as much as you do, or have your experiences – but damn are their jobs are hard. If you have a good Service Desk they work as a master-class filtration engine, sorting the crap away from your consultants and making users with low-level tickets happy by solving them at first contact. Treasure them! They’re the face of your organization. I’ve heard names like Desklings or Service gnomes and it’s not acceptable. If you want your expensive and highly certified consultants stuck with 83 year old “Gerd” from a carpet laying company who can’t open Outlook for 3 hours, you go with the name calling. If not: Cherish your Service Desk Consultants.

Your communication matters and so does your intention.

Thank you for reading.

And if you ever read this Eirin: Thank you for the hard lesson. I’m sorry.